dcollections 1.0 and 2.0a beta released

[Andrei Alexandrescu]

On 05/20/2010 08:22 AM, Steven Schveighoffer wrote:
> Michel Fortin Wrote:
>
>> On 2010-05-20 06:34:42 -0400, Steven
>> Schveighoffer<schveiguy at 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 instantiated to
>>> copy data from all the other containers.  The problem with using
>>> generic code is that the compiler will needlessly duplicate
>>> functions that are identical.
>>
>> One question. Have you calculated the speed difference between
>> using an interface and using generic code? Surely going through all
>> those virtual calls slows things down a lot.
>>
>> I do like interfaces in principle, but I fear it'll make things
>> much slower when people implement things in term of interfaces.
>> That's why I'm not sure it's a good idea to offer container
>> interfaces in the standard library.
>
> It's not that much slower.  You get a much higher speedup when things
> can be inlined than virtual vs. non-virtual.
>
> However, I should probably make all the functions in the concrete
> implementations final.  I made several of them final, but I should do
> it across the board.

Yup. Even Java does that. I forgot whether it was a recanting of a 
former stance (as was the case with synchronized) or things were like 
that from the get-go.

> 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.

Of course it would be possible. You write a generic function that takes 
two generic container and constrain the inputs such that at least one 
has element lookup capability. (Complexity-oriented design for the win!)


Andrei