Semantics of toString

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> On Thu, 12 Nov 2009 13:46:08 -0500, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
> 
>>>   From my C++ book, it appears to only use virtual inheritance.  I 
>>> don't know enough about virtual inheritance to know how that changes 
>>> function calls.
>>>  As far as virtual functions, only the destructor is virtual, so 
>>> there is no issue there.
>>
>> You're right, but there is an issue because as far as I can recall 
>> these functions' implementation do end up calling a virtual function 
>> per char; that might be streambuf.overflow. I'm not keen on 
>> investigating this any further, but I'd be grateful if you shared any 
>> related knowledge.
> 
> Yep, you are right.  It appears the reason they do this is so the 
> conversion to the appropriate width can be done per character (and is a 
> no-op for char).
> 
>> At the end of the day, there seem to be violent agreement that we 
>> don't want one virtual call per character or one delegate call per 
>> character.
> 
> After running my tests, it appears the virtual call vs. delegate is so 
> negligible, and the virtual call vs. direct call is only slightly less 
> negligible, I think the virtualness may not matter.  However, I think 
> avoiding one *call* per character is a worthy goal.
> 
> This doesn't mean I change my mind :)  I still think there is little 
> benefit to having to conjure up an entire object just to convert 
> something to a string vs. writing a simple inner function.
> 
> One way to find out is to support only char[], and see who complains :)  
> It'd be much easier to go from supporting char[] to supporting all the 
> widths than going from supporting all to just one.

One problem I just realized is that, if we e.g. offer only put(in 
char[]) or a delegate to that effect, we make it impossible to output 
one character efficiently. The (&c)[0 .. 1] trick will not work in safe 
mode. You'd have to allocate a one-element array dynamically.

Also, many OSs adopted UTF-16 as their standard format. It may be wise 
to design for compatibility.


Andrei