Semantics of toString
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Thu Nov 12 08:48:00 PST 2009
Don 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.
>
> How? It seems to introduce more requirements on the implementation, but
> I'm not seeing any benefit in exchange.
The benefit is that it allows writing all character widths.
> 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.
That seems plausible.
Andrei
More information about the Digitalmars-d
mailing list