On 20/05/10 13:39, Bernard Helyer wrote:
Oooohhh goody goody goody! n_n
I'm in the process of making a little toy project ATM. I'll shall
integrate dcollections 2.0a into ASAP.
ArrayList doesn't compile with warnings as it overrides opEquals, but
doesn't mark it as such.
On 20/05/10 18:11, Bernard Helyer wrote:
On 20/05/10 13:39, Bernard Helyer wrote:
Oooohhh goody goody goody! n_n
I'm in the process of making a little toy project ATM. I'll shall
integrate dcollections 2.0a into ASAP.
ArrayList doesn't compile with warnings as it overrides opEquals, but
On 20/05/10 18:16, Bernard Helyer wrote:
On 20/05/10 18:11, Bernard Helyer wrote:
On 20/05/10 13:39, Bernard Helyer wrote:
Oooohhh goody goody goody! n_n
I'm in the process of making a little toy project ATM. I'll shall
integrate dcollections 2.0a into ASAP.
ArrayList doesn't compile with
Phil Deets wrote:
On Wed, 19 May 2010 22:28:26 -0600, Phil Deets pjdee...@gmail.com wrote:
On Wed, 19 May 2010 18:31:53 -0600, Walter Bright
newshou...@digitalmars.com wrote:
Title: The Anatomy of Message Passing
Speaker: Bartosz Milewski
Date: May 19, 2010
Time: 7 pm
Place: Microsoft
Robert Jacques Wrote:
On Wed, 19 May 2010 21:42:35 -0400, Steven Schveighoffer
Does that make sense?
-Steve
Yes and No. I understand where your coming from, but I think it's a bad
idea. First, I think it needlessly expands the radius of comprehension
needed to understand and
Michel Fortin:
Surely going through all those virtual calls slows things down a lot.
Right. But the purpose of a good compiler is to kill those, devirtualizing.
LLVM devs are working on this too. See:
http://llvm.org/bugs/show_bug.cgi?id=6054
http://llvm.org/bugs/show_bug.cgi?id=3100
Michel Fortin Wrote:
On 2010-05-20 06:34:42 -0400, Steven Schveighoffer schvei...@yahoo.com said:
I understand these points, but I'm already using interfaces to copy
data between containers. I don't have to, I could have used generic
code, but this way, only one function is
On 05/20/2010 03:22 PM, Steven Schveighoffer wrote:
One thing I just thought of -- in dcollections, similar types can be compared
to one another. For example, you can check to see if a HashSet is equal to a
TreeSet. But that would not be possible without interfaces.
-Steve
I'm sorry, but
On 2010-05-20 09:22:27 -0400, Steven Schveighoffer schvei...@yahoo.com said:
Michel Fortin Wrote:
On 2010-05-20 06:34:42 -0400, Steven Schveighoffer schvei...@yahoo.com said:
I understand these points, but I'm already using interfaces to copy
data between containers. I don't have to, I
On 2010-05-20 08:30:59 -0400, bearophile bearophileh...@lycos.com said:
Michel Fortin:
Surely going through all those virtual calls slows things down a lot.
Right. But the purpose of a good compiler is to kill those,
devirtualizing. LLVM devs are working on this too. See:
Steven Schveighoffer:
You get a much higher speedup when things can be inlined than virtual vs.
non-virtual.
In current D compilers virtual functions prevent inlining. This can give some
performance loss.
Bye,
bearophile
On Thu, 20 May 2010 06:34:42 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
Robert Jacques Wrote:
On Wed, 19 May 2010 21:42:35 -0400, Steven Schveighoffer
Does that make sense?
-Steve
Yes and No. I understand where your coming from, but I think it's a bad
idea. First, I think it
On 05/19/2010 07:21 PM, bearophile wrote:
Andrei Alexandrescu:
Destroy me :o).
You ideas are surely interesting, but I don't think there's a simple way to
change his code according to your ideas.
People can use the dcollections in the following weeks and months, and when you
have
Michel Fortin:
Devirtualization is only possible in certain cases: when the function knows
exactly which type it'll get.
You are wrong, in most cases there are ways to de-virtualize, even when the
runtime type isn't exactly known, but sometimes to do it you have to work too
much. This is
On 2010-05-20 15:47:22 -0400, bearophile bearophileh...@lycos.com said:
Michel Fortin:
Devirtualization is only possible in certain cases: when the function
knows exactly which type it'll get.
You are wrong, in most cases there are ways to de-virtualize, even when
the runtime type isn't
Michel Fortin Wrote:
On 2010-05-20 09:22:27 -0400, Steven Schveighoffer schvei...@yahoo.com said:
Michel Fortin Wrote:
On 2010-05-20 06:34:42 -0400, Steven Schveighoffer schvei...@yahoo.com
said:
I understand these points, but I'm already using interfaces to copy
data between
Pelle Wrote:
On 05/20/2010 03:22 PM, Steven Schveighoffer wrote:
One thing I just thought of -- in dcollections, similar types can be
compared to one another. For example, you can check to see if a HashSet is
equal to a TreeSet. But that would not be possible without interfaces.
bearophile Wrote:
Steven Schveighoffer:
You get a much higher speedup when things can be inlined than virtual vs.
non-virtual.
In current D compilers virtual functions prevent inlining. This can give some
performance loss.
People seem to think that because dcollections implement
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
Andrei Alexandrescu Wrote:
To get back to one of my earlier points, the fact that the container
interfaces are unable to express iteration is a corollary of the
design's problem and an climactic disharmony.
My vision, in
19 matches
Mail list logo
