Semantics of toString

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> On Thu, 12 Nov 2009 14:40:12 -0500, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
> 
>> 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.
> 
> char[1] buf;
> buf[0] = c;
> put(buf);

This would not compile in SafeD.

> Although it would be a useful feature to be able to convert a value type 
> to an array of one element reference, especially since that should be as 
> safe as taking a slice of a static array.
> 
> Another solution, although I'm unaware of the added costs:
> 
> void toString(void delegate(in char[]...) put, string fmt);
> 
>> Also, many OSs adopted UTF-16 as their standard format. It may be wise 
>> to design for compatibility.
> 
> So you want toString's to look like this?
> 
> version(utf16isdefault)
> {
>   textobj.put("Array: "w);
>   ...
> }
> else
> {
>   textobj.put("Array: ");
>   ...
> }
> 
> -Steve


I was just thinking of offering an interface that offers utf8 and utf16 
and utf32.


Andrei