Excuse me, because I haven't been active in the D community the last
year due to school concerns. However, I have been fiddling with the
language and on this newsgroups since 2001.
As I understand it, dynamic arrays are going away soon in D2.0 in
favor of an ArrayBuilder class.
I don't li
Don Wrote:
> BTW, does Python allow integer division of floating point numbers?
> eg, int_a = float_b // float_c; ?
> (meaning cast(int)float_b / (cast(int)float_c); ).
Python doesn't have integer division, but floor division, and it's perefctly
valid if arguments are floats, as name says it's
"bearophile" wrote in message
news:hg6rns$ta...@digitalmars.com...
>
>
> Even if you find a fitting operator, how can you restrict \ to just
> floating point division
> and keep some compatibility with C code?
Isnt compatibility with C already broken anyway?
But yeah if C compatibility is a c
On 2009-11-20 02:18:03 -0800, Pelle Månsson said:
Andrei Alexandrescu wrote:
Bill Baxter wrote:
On Thu, Nov 19, 2009 at 8:46 AM, Andrei Alexandrescu
wrote:
grauzone wrote:
What's with opSomethingAssign (or "expr1[expr2] @= expr3" in general)?
opBinary doesn't seem to solve any of those.
o
On 2009-11-19 15:46:57 -0800, Bill Baxter said:
On Wed, Nov 18, 2009 at 8:33 PM, Andrei Alexandrescu
wrote:
I am thinking that representing operators by their exact token
representation is a principled approach because it allows for unambiguous
mapping,
There used to be an argument floatin
On 2009-12-14 11:04:53 -0800, Leandro Lucarella said:
lws, el 14 de diciembre a las 08:31 me escribiste:
Unless I'm confused, classses are ALWAYS heap (unless explicitely
scoped) objects in D.
Yes, and classes are always references too. But that's not even the point,
the point is, the exampl
On Mon, 14 Dec 2009 04:57:26 -0500, Don wrote:
In the very rare cases where the result of an integer division was
actually intended to be stored in a float, an explicit cast would be
required. So you'd write:
double y = cast(int)(1/x);
To me,
double y = cast(double)(1/x);
makes more sen
"Michel Fortin" wrote in message
news:hg6she$ub...@digitalmars.com...
> On 2009-12-14 20:56:12 -0500, "Nick Sabalausky" said:
>
>> "Andrei Alexandrescu" wrote in message
>> news:hg698i$2rp...@digitalmars.com...
>>> Maybe opDispatch could help the use scenario.
>>>
>>> Andrei
>>
>> As opDispatch
Don Wrote:
> Walter Bright wrote:
> > Don wrote:
> >> Consider this notorious piece of code:
> >>
> >> assert(x>1);
> >> double y = 1 / x;
> >>
> >> This calculates y as the reciprocal of x, if x is a floating-point
> >> number. But if x is an integer, an integer division is performed
> >> inste
On 2009-12-14 20:56:12 -0500, "Nick Sabalausky" said:
"Andrei Alexandrescu" wrote in message
news:hg698i$2rp...@digitalmars.com...
Maybe opDispatch could help the use scenario.
Andrei
As opDispatch pushes errors from compile-time to run-time, I don't think we
should be encouraging its use
bearophile Wrote:
> Sean Kelly:
> > If I had to guess I'd say that he's referring to that fact that value types
> > in Java are second-class citizens. The standard containers can only hold
> > objects, so boxing is necessary,<
>
> Reading that page I have thought he wants all data to be manage
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:hg698i$2rp...@digitalmars.com...
Michel Fortin wrote:
On 2009-12-14 11:41:58 -0500, Andrei Alexandrescu
said:
Adam D. Ruppe wrote:
On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
D2 will include proper
== Quote from Dan (dsstruth...@yahoo.com)'s article
> I have a question regarding performance issue I am seeing on multicore Windows
systems. I am creating many threads to do parallel tasks, and on multicore
Windows systems the performance is abysmal. If I use task manager to set the
processor af
Bob Jones:
> The fact that adding a specific intdiv operator would not only avoid more
> casting, but remove the the need for casting in a lot of existing cases
> should count pretty well against the "no more operator/keywords" argument.
In D you can't use // used in Python, because it's used to
"Don" wrote in message
news:hg5nkk$1n3...@digitalmars.com...
> bearophile wrote:
>> Don:
In Pascal too (and OCaML, but the situation is different) they are
separated. I think here having two operators is better,
>>> Why?
>>
>> You are intelligent and expert so you must know my answer,
"Andrei Alexandrescu" wrote in message
news:hg698i$2rp...@digitalmars.com...
> Michel Fortin wrote:
>> On 2009-12-14 11:41:58 -0500, Andrei Alexandrescu
>> said:
>>
>>> Adam D. Ruppe wrote:
On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
> D2 will include propertie
There are things that I read often around in blogs and papers (and sometimes
even in books), but sometimes I keep not understanding them.
Sean Kelly:
> If I had to guess I'd say that he's referring to that fact that value types
> in Java are second-class citizens. The standard containers can on
I have a question regarding performance issue I am seeing on multicore Windows
systems. I am creating many threads to do parallel tasks, and on multicore
Windows systems the performance is abysmal. If I use task manager to set the
processor affinity to a single CPU, the program runs as I would
bearophile Wrote:
> This is a mostly boring rant against the Go language:
> http://monoc.mo.funpic.de/go-rant/
>
> Near the end it contains an interesting bit:
> >Too, why this divide, again, with reference types and value types? Did they
> >not learn from the problems this caused in Java? While
This is a mostly boring rant against the Go language:
http://monoc.mo.funpic.de/go-rant/
Near the end it contains an interesting bit:
>Too, why this divide, again, with reference types and value types? Did they
>not learn from the problems this caused in Java? While Java slowly struggles
>its wa
Denis Koroskin wrote:
On Mon, 14 Dec 2009 23:38:34 +0300, Andrei Alexandrescu
wrote:
Denis Koroskin wrote:
On Mon, 14 Dec 2009 21:06:20 +0300, dsimcha wrote:
I mentioned this deep in another thread, but I think it deserves its
own
thread. Can we get something like:
void doStuff(T)(cons
Denis Koroskin wrote:
On Mon, 14 Dec 2009 22:15:06 +0300, Andrei Alexandrescu
wrote:
Eldar Insafutdinov wrote:
dsimcha Wrote:
I mentioned this deep in another thread, but I think it deserves its
own
thread. Can we get something like:
void doStuff(T)(const ref T val) {
// do stuff.
}
On 2009-12-14 16:04:18 -0500, Andrei Alexandrescu
said:
Michel Fortin wrote:
On 2009-12-14 11:41:58 -0500, Andrei Alexandrescu
said:
Adam D. Ruppe wrote:
On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
D2 will include properties that are understood by the compiler. W
On Mon, 14 Dec 2009 23:38:34 +0300, Andrei Alexandrescu
wrote:
Denis Koroskin wrote:
On Mon, 14 Dec 2009 21:06:20 +0300, dsimcha wrote:
I mentioned this deep in another thread, but I think it deserves its
own
thread. Can we get something like:
void doStuff(T)(const ref T val) {
//
On Mon, 14 Dec 2009 22:15:06 +0300, Andrei Alexandrescu
wrote:
Eldar Insafutdinov wrote:
dsimcha Wrote:
I mentioned this deep in another thread, but I think it deserves its
own
thread. Can we get something like:
void doStuff(T)(const ref T val) {
// do stuff.
}
T getVal() {
re
== Quote from Jason House (jason.james.ho...@gmail.com)'s article
> If T is a class, I agree it should work. If T is a struct, you'll need a
stronger argument. Maybe scope const ref T would make sense. IMHO, non- scope
ref
T for structs is already a questionable practice, and I don't mind the comp
Michel Fortin wrote:
On 2009-12-14 11:41:58 -0500, Andrei Alexandrescu
said:
Adam D. Ruppe wrote:
On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
D2 will include properties that are understood by the compiler. We
currently don't have a design for user-defined properties
On 2009-12-14 11:41:58 -0500, Andrei Alexandrescu
said:
Adam D. Ruppe wrote:
On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
D2 will include properties that are understood by the compiler. We
currently don't have a design for user-defined properties.
Can I suggest some
Don:
>You've used Python extensively, I haven't.<
The situation with Python isn't the same of D because Python has dynamic
typing, so your operations must always know what they return (and their return
type can change when necessary).
>in what contexts is / ambiguous or difficult to read?<
A
Denis Koroskin wrote:
On Mon, 14 Dec 2009 21:06:20 +0300, dsimcha wrote:
I mentioned this deep in another thread, but I think it deserves its own
thread. Can we get something like:
void doStuff(T)(const ref T val) {
// do stuff.
}
T getVal() {
return someValue;
}
void main() {
On Mon, 14 Dec 2009 21:06:20 +0300, dsimcha wrote:
I mentioned this deep in another thread, but I think it deserves its own
thread. Can we get something like:
void doStuff(T)(const ref T val) {
// do stuff.
}
T getVal() {
return someValue;
}
void main() {
doStuff(getVal()); //
dsimcha Wrote:
> I mentioned this deep in another thread, but I think it deserves its own
> thread. Can we get something like:
>
> void doStuff(T)(const ref T val) {
> // do stuff.
> }
>
> T getVal() {
> return someValue;
> }
>
> void main() {
> doStuff(getVal()); // Doesn't curre
On 12/14/09 20:29, Jacob Carlborg wrote:
On 12/13/09 20:44, Eldar Insafutdinov wrote:
Nick Sabalausky Wrote:
"Nick Sabalausky" wrote in message
news:hg394f$mr...@digitalmars.com...
"Eldar Insafutdinov" wrote in message
news:hg2p87$2tt...@digitalmars.com...
1) You may know the concept of sig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sean Kelly wrote:
> Don Wrote:
>
>> Walter Bright wrote:
>>> Don wrote:
(This means that double y = int_val / 1; is OK, and also:
double z = 90/3; would be OK. An alternative rule would be:
"If an integer expression involves integer d
On 12/13/09 20:44, Eldar Insafutdinov wrote:
Nick Sabalausky Wrote:
"Nick Sabalausky" wrote in message
news:hg394f$mr...@digitalmars.com...
"Eldar Insafutdinov" wrote in message
news:hg2p87$2tt...@digitalmars.com...
1) You may know the concept of signals and slots in Qt. Consider the
follo
Eldar Insafutdinov wrote:
dsimcha Wrote:
I mentioned this deep in another thread, but I think it deserves its own
thread. Can we get something like:
void doStuff(T)(const ref T val) {
// do stuff.
}
T getVal() {
return someValue;
}
void main() {
doStuff(getVal()); // Doesn't cu
lws, el 14 de diciembre a las 08:31 me escribiste:
> Unless I'm confused, classses are ALWAYS heap (unless explicitely
> scoped) objects in D.
Yes, and classes are always references too. But that's not even the point,
the point is, the example was a struct :)
> >>>struct Foo {
> >>>bool opEquals(
dsimcha Wrote:
> I mentioned this deep in another thread, but I think it deserves its own
> thread. Can we get something like:
>
> void doStuff(T)(const ref T val) {
> // do stuff.
> }
>
> T getVal() {
> return someValue;
> }
>
> void main() {
> doStuff(getVal()); // Doesn't curre
Ignore this, it's caused by the online interface, sorry.
Don wrote:
Integer expressions remain inexact until there's a cast.
(It's very simple to implement, you just use the integer range code,
adding an 'inexact' flag. Division sets the flag, casts clear the flag,
everything else just propagates it if a unary operation, or ORs the two
flags if a b
I mentioned this deep in another thread, but I think it deserves its own
thread. Can we get something like:
void doStuff(T)(const ref T val) {
// do stuff.
}
T getVal() {
return someValue;
}
void main() {
doStuff(getVal()); // Doesn't currently work.
}
For non-const ref parameters
Matthew:
A cleaned up case:
struct B { A a; }
static if(true)
struct A {}
void main() {}
I think this may be a forward reference bug...
Bye,
bearophile
== Quote from lws (inva...@email.com)'s article
> On 2009-12-14 07:01:47 -0800, dsimcha said:
> > == Quote from lws (inva...@email.com)'s article
> >> I don't know if I believe this is necesarrily bad. It's revealing some
> >> bad coding on your part.
> >> You shouldn't be doing opEquals with an
Denis Koroskin wrote:
> On Mon, 14 Dec 2009 11:04:15 +0300, Lutger
> wrote:
>
>> What are you planning to with multithreading?
>>
>> With the current type system, is it possible to statically detect inside
>> the
>> template if the refcount is used in shared scenario's, and base the
>> implement
"bobef" wrote in message
news:hg5qr6$1t9...@digitalmars.com...
> Andrei Alexandrescu Wrote:
>
>> > I would say that QtD is in the state close to that of D2, almost
>> > there, but not quite ready yet. But we intend to release the next
>> > version, which will be ready to use earlier than D2 anywa
"Kagamin" wrote in message
news:hg5bnt$110...@digitalmars.com...
> Nick Sabalausky Wrote:
>
>>- Many GTK apps use the absolute *worst* and most impractical file
>> dialog
>> boxes I've seen in over 15 years. This is never an issue with native
>> apps.
>
> I like how gimp dialog box provides
Andrei Alexandrescu Wrote:
> > I would say that QtD is in the state close to that of D2, almost
> > there, but not quite ready yet. But we intend to release the next
> > version, which will be ready to use earlier than D2 anyway, I would
> > say within a month.
>
> I salute the decision of going
On 2009-12-14 03:16:27 -0800, Don said:
Walter Bright wrote:
Don wrote:
Consider this notorious piece of code:
assert(x>1);
double y = 1 / x;
This calculates y as the reciprocal of x, if x is a floating-point
number. But if x is an integer, an integer division is performed
instead of a fl
Adam D. Ruppe wrote:
On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
D2 will include properties that are understood by the compiler. We
currently don't have a design for user-defined properties.
Can I suggest something very simple: make them accessible from __traits,
and l
On 2009-12-14 07:01:47 -0800, dsimcha said:
== Quote from lws (inva...@email.com)'s article
I don't know if I believe this is necesarrily bad. It's revealing some
bad coding on your part.
You shouldn't be doing opEquals with an rvalue of a class. Make
getFoo return a reference.
ref Foo getF
Unless I'm confused, classses are ALWAYS heap (unless explicitely
scoped) objects in D. The garbage collector is the one that is tasked
with reclaiming their memory and calling their deconstructor.
If you want the semantics you're talking about Foo would need to be a
"scoped Foo foo = new Fo
On Mon, Dec 14, 2009 at 07:42:51AM -0800, Andrei Alexandrescu wrote:
> Probably it's easier to (also) offer is(a == @myprop).
Yeah, that works too. As long as we have some kind of building block.
> But we couldn't make static foreach part of D2.
Oh well, no big deal; we can make do without it.
bearophile wrote:
Don:
In Pascal too (and OCaML, but the situation is different) they are separated. I think here having two operators is better,
Why?
You are intelligent and expert so you must know my answer, so I fear yours is a
trick question :-)
No, it's not a trick question. You've us
dsimcha Wrote:
> I'm starting to think it would be both useful and feasible to have a general
> reference counting template struct in Phobos:
> [...]
> Does this sound
> worthwhile?
Yes it does :-)
I believe this would be great for working with many C-based APIs. I recently
needed this when cre
Don wrote
> Consider this notorious piece of code:
>
> assert(x>1);
> double y = 1 / x;
>
> This calculates y as the reciprocal of x, if x is a floating-point number.
> But if x is an integer, an integer division is performed instead of a
> floating-point one, and y will be 0.
>
> It's a very com
Don Wrote:
> Walter Bright wrote:
> > Don wrote:
> >>
> >> (This means that double y = int_val / 1; is OK, and also:
> >> double z = 90/3; would be OK. An alternative rule would be:
> >> "If an integer expression involves integer divison, that expression
> >> cannot be implicitly cast to a floa
Adam D. Ruppe wrote:
On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
D2 will include properties that are understood by the compiler. We
currently don't have a design for user-defined properties.
Can I suggest something very simple: make them accessible from __traits,
and l
On Mon, Dec 14, 2009 at 07:24:11AM -0800, Andrei Alexandrescu wrote:
> D2 will include properties that are understood by the compiler. We
> currently don't have a design for user-defined properties.
Can I suggest something very simple: make them accessible from __traits,
and leave the rest to the
Eldar Insafutdinov wrote:
Andrei Alexandrescu Wrote:
Eldar Insafutdinov wrote:
Andrei Alexandrescu Wrote:
Thanks for cooperation. I don't want to sound like I've given the
right to ask for features, because I am working on a particular D
project. But at the same time, indeed, while working on
"bearophile" wrote:
> Don:
>> > In Pascal too (and OCaML, but the situation is different) they are
>> > separated. I think here having two operators is better,
>>
>> Why?
>
> You are intelligent and expert so you must know my answer, so I fear yours
> is a trick question :-)
>
> Two operators a
== Quote from lws (inva...@email.com)'s article
> I don't know if I believe this is necesarrily bad. It's revealing some
> bad coding on your part.
> You shouldn't be doing opEquals with an rvalue of a class. Make
> getFoo return a reference.
> ref Foo getFoo() {} fixes the problem and avoids va
== Quote from Lutger (lutger.blijdest...@gmail.com)'s article
> What are you planning to with multithreading?
> With the current type system, is it possible to statically detect inside the
> template if the refcount is used in shared scenario's, and base the
> implementation on that information? Th
lws, el 14 de diciembre a las 01:06 me escribiste:
> I don't know if I believe this is necesarrily bad. It's revealing
> some bad coding on your part.
>
> You shouldn't be doing opEquals with an rvalue of a class. Make
> getFoo return a reference.
>
> ref Foo getFoo() {} fixes the problem and
Don:
> > In Pascal too (and OCaML, but the situation is different) they are
> > separated. I think here having two operators is better,
>
> Why?
You are intelligent and expert so you must know my answer, so I fear yours is a
trick question :-)
Two operators allow to reduce the need for casts
bearophile wrote:
Don:
In the opPow thread there were a couple of mentions of inadvertent
integer division, and how Python is removing this error by making /
always mean floating-point division, and introducing a new operator for
integer division.
In Pascal too (and OCaML, but the situation
Nick Sabalausky Wrote:
>- Many GTK apps use the absolute *worst* and most impractical file dialog
> boxes I've seen in over 15 years. This is never an issue with native apps.
I like how gimp dialog box provides mruds, which is not done by virtually any
other windows application, this is ext
Don:
> In the opPow thread there were a couple of mentions of inadvertent
> integer division, and how Python is removing this error by making /
> always mean floating-point division, and introducing a new operator for
> integer division.
In Pascal too (and OCaML, but the situation is different)
Walter Bright wrote:
Don wrote:
Consider this notorious piece of code:
assert(x>1);
double y = 1 / x;
This calculates y as the reciprocal of x, if x is a floating-point
number. But if x is an integer, an integer division is performed
instead of a floating-point one, and y will be 0.
It's a
On Mon, Dec 14, 2009 at 2:24 AM, Lars T. Kyllingstad
wrote:
> dsimcha wrote:
>>
>> == Quote from retard (r...@tard.com.invalid)'s article
>>>
>>> Sat, 12 Dec 2009 05:10:24 +, dsimcha wrote:
2. Native look and feel. IMHO this is very overrated. I've never
found that a Java-ish
dsimcha wrote:
== Quote from retard (r...@tard.com.invalid)'s article
Sat, 12 Dec 2009 05:10:24 +, dsimcha wrote:
2. Native look and feel. IMHO this is very overrated. I've never
found that a Java-ish or GTK-ish or whatever look and feel instead of a
native Win32 look and feel got in the
Don wrote:
Consider this notorious piece of code:
assert(x>1);
double y = 1 / x;
This calculates y as the reciprocal of x, if x is a floating-point
number. But if x is an integer, an integer division is performed instead
of a floating-point one, and y will be 0.
It's a very common newbie tr
Consider this notorious piece of code:
assert(x>1);
double y = 1 / x;
This calculates y as the reciprocal of x, if x is a floating-point
number. But if x is an integer, an integer division is performed instead
of a floating-point one, and y will be 0.
It's a very common newbie trap, but I fi
On Mon, 14 Dec 2009 11:04:15 +0300, Lutger
wrote:
What are you planning to with multithreading?
With the current type system, is it possible to statically detect inside
the
template if the refcount is used in shared scenario's, and base the
implementation on that information? That would b
On 2009-12-13 04:29:28 -0800, Steven Schveighoffer said:
Richard Webb Wrote:
Hi,
I mentioned this problem in the thread @
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=18405
I
ran into the rvalue problem while trying to get Juno to compile, an
I don't know if I believe this is necesarrily bad. It's revealing some
bad coding on your part.
You shouldn't be doing opEquals with an rvalue of a class. Make
getFoo return a reference.
ref Foo getFoo() {} fixes the problem and avoids value-copying for no
reason to an rvalue that's going
What are you planning to with multithreading?
With the current type system, is it possible to statically detect inside the
template if the refcount is used in shared scenario's, and base the
implementation on that information? That would be ideal, if it is indeed
possible.
std.stdio.File is r
Andrei Alexandrescu Wrote:
> Eldar Insafutdinov wrote:
> > Andrei Alexandrescu Wrote:
> > Thanks for cooperation. I don't want to sound like I've given the
> > right to ask for features, because I am working on a particular D
> > project. But at the same time, indeed, while working on this project
77 matches
Mail list logo
