Semantics of toString

[Don]

Andrei Alexandrescu wrote:
> 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.

How? It seems to introduce more requirements on the implementation, but 
I'm not seeing any benefit in exchange.

FWIW, with regard to performance, I can easily imagine the compiler 
being able to perform the equivalent of a "named return value" 
optimisation on a delegate return, giving some chance of inlining.
That's a lot less obvious with an interface.