it's time to change how things are printed

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Nov 18 09:02:54 PST 2010


On 11/18/10 7:14 AM, Steven Schveighoffer wrote:
> A recent bug report reminded me of how horrible D is at printing custom
> types.
>
> Consider a container type that contains 1000 elements, such as a linked
> list. If you print this type, you would expect to get a printout similar
> to an array, i.e.:
>
> [ 1 2 3 4 5 ... 1000 ]
>
> If you do this:
>
> writeln(mylist);
>
> then what happens is, writeln calls mylist.toString(), and prints that
> string.
>
> But inside mylist.toString, it likely does things like
> elem[0].toString() and concatenates all these together. This results in
> at least 1000 + 1 heap allocations, to go along with 1000 appends, to
> create a string that will be sent to an output stream and *discarded*.
>
> So the seemingly innocuous line writeln(mylist) is like attaching a boat
> anchor to your code performance.
>
> There is a better way, as demonstrated by BigInt (whose author refuses
> to implement toString()):
>
> void toString(scope void delegate(scope const(char)[] data), string
> format = null)
>
> What does this do? Well, now, writeln can define a delegate that takes a
> string and sends it to an output stream. Now, there is no copying of
> data, no heap allocations, and no need to concatenate anything together!
> Not only that, but it can be given an optional format specifier to
> control output when writefln is used. Let's see how a linked list would
> implement this function (ignoring format for now):
>
> void toString(scope void delegate(scope const(char)[] data) sink, string
> format = null)
> {
> sink("[");
> foreach(elem; this)
> {
> sink(" ");
> elem.toString(sink);
> }
> sink(" ]");
> }
>
> It looks just about as simple as the equivalent function that would
> currently be necessary, except you have *no* heap allocations, there is
> a possibility for formatting, and D will be that much better performing.
> Note that using a delegate allows much more natural code which requires
> recursion.
>
> Should we create a DIP for this? I'll volunteer to spearhead the effort
> if people are on board.
>
> -Steve

Yes please.

Andrei


More information about the Digitalmars-d mailing list