Semantics of toString

[Andrei Alexandrescu]

Justin Johansson wrote:
> 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.
>>
>> 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?

My understanding is that the costs are comparable.

Andrei