Semantics of toString

[Denis Koroskin]

On Thu, 12 Nov 2009 16:23:22 +0300, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Thu, 12 Nov 2009 08:22:26 -0500, Steven Schveighoffer  
> <schveiguy at yahoo.com> wrote:
>
>> On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu  
>> <SeeWebsiteForEmail at erdani.org> 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).