dcollections 1.0 and 2.0a beta released
BCS
none at anon.com
Fri May 21 20:51:57 PDT 2010
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><
More information about the Digitalmars-d-announce
mailing list