Semantics of toString

[Andrei Alexandrescu]

Denis Koroskin wrote:
> 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).

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