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