Andrei Alexandrescu Wrote: > Denis Koroskin wrote: > > On Thu, 12 Nov 2009 16:23:22 +0300, Steven Schveighoffer > > <[email protected]> wrote: > > > >> On Thu, 12 Nov 2009 08:22:26 -0500, Steven Schveighoffer > >> <[email protected]> wrote: > >> > >>> On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu > >>> <[email protected]> wrote: > >>> > >>>> I think the best option for toString is to take an output range and > >>>> write to it. (The sink is a simplified range.) > >>> > >>> Bad idea... > >>> > >>> A range only makes sense as a struct, not an interface/object. I'll > >>> tell you why: performance. > >>> > >>> Ranges are special in two respects: > >>> > >>> 1. They are foreachable. I think everyone agrees that calling 2 > >>> interface functions per loop iteration is much lower performing than > >>> using opApply, which calls one delegate function per loop. My > >>> recommendation -- use opApply when dealing with polymorphism. I > >>> don't think there's a way around this. > >> > >> Oops, I meant 3 virtual functions -- front, popNext, and empty. > >> > >> -Steve > > > > Output range has only one method: put. > > > > I'm not sure, but I don't think there is a performance difference > > between calling a virtual function through an interface and invoking a > > delegate. > > > > But I agree passing a delegate is more generic. You can substitute an > > output range with a delegate (obj.toString(&range.put, fmt)) without any > > performance hit, but not vice versa (obj.toString(new > > DelegateWrapRange(&myput), fmt) implies an additional allocation and > > additional indirection per range.put call). > > I think that, on the contrary, working with a delegate is less generic. > A delegate is cost-wise much like a class with only one (non-final) > method. Since we're taking that hit already, we may as well define > actual interfaces and classes that have multiple methods. That makes > things more flexible and more efficient. > > Andrei
"Since we're taking that hit already, we may as well define > actual interfaces and classes that have multiple methods." Which you mean -- interfaces, classes or both? Don't interfaces have a higher cost than classes? Justin
