dcollections 1.0 and 2.0a beta released

[BCS]

Hello Andrei,

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

Cool. Now how do I write code so that it will always iterate the collection 
with the bigger O() lookup time (O(n) before O(log2(n)) before O(log16(n)) 
before O(1))? :D

-- 
... <IXOYE><