On 05/20/2010 08:22 AM, Steven Schveighoffer wrote:
Michel Fortin Wrote:
On 2010-05-20 06:34:42 -0400, Steven
Schveighoffer<[email protected]> 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
