Steven Schveighoffer wrote:
On Thu, 12 Nov 2009 14:40:12 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Steven Schveighoffer wrote:
On Thu, 12 Nov 2009 13:46:08 -0500, Andrei Alexandrescu
<seewebsiteforem...@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
