Michel Fortin Wrote: > On 2010-05-20 09:22:27 -0400, Steven Schveighoffer <schvei...@yahoo.com> said: > > > 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. > > Yes, but that was part of the equation: a call to a template function > can be inlined, not a virtual call (most of the time).
So if you want inlining, use the actual type, nothing is stopping you. Well, except the non-final functions, I have to fix that. > > 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. > > I'm not sure of what you're saying here. Are you saying it can be done > with an interface but not with a template type? Why can't this work: Because comparing two objects for equality now calls this function: bool opEquals(Object obj1, Object obj2) Which is defined in object_.d in the runtime. No compile-time anything is allowed. -Steve