Re: Efficient outputting of to-string conversions
On Monday 07 February 2011 13:10:09 Tomek Sowiński wrote: > Looks like std.conv.to always allocates behind the scenes. It's a shame as > the returned string is immediately processed and discarded in my XML > writer. Are there plans to include a custom output variant, e.g. > to!string(7, outputRange)? http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9
Re: Efficient outputting of to-string conversions
Jonathan M Davis napisał: > On Monday 07 February 2011 13:10:09 Tomek Sowiński wrote: > > Looks like std.conv.to always allocates behind the scenes. It's a shame as > > the returned string is immediately processed and discarded in my XML > > writer. Are there plans to include a custom output variant, e.g. > > to!string(7, outputRange)? > > http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 I know about Steven's proposal but it applies only to user types not primitives. Either way std.conv.to would need a buffered output range as integers are written from the right. Any chance for an abstraction analogous to buffered input ranges discussed recently? -- Tomek
Re: Efficient outputting of to-string conversions
On 2/7/11 4:43 PM, Jonathan M Davis wrote: On Monday 07 February 2011 13:10:09 Tomek Sowiński wrote: Looks like std.conv.to always allocates behind the scenes. It's a shame as the returned string is immediately processed and discarded in my XML writer. Are there plans to include a custom output variant, e.g. to!string(7, outputRange)? http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 Yah, we should hop on that. The DIP is concerned mainly with toString, not std.conv. For the latter, Tomek's idea of passing an output range as an optional second parameter seems appropriate. Please file as an enhancement to bugzilla. If anyone has time to work on this, please do. If not, I'll work on it as my schedule allows. Andrei
Re: Efficient outputting of to-string conversions
On 2/7/11 5:38 PM, Tomek Sowiński wrote: Jonathan M Davis napisał: On Monday 07 February 2011 13:10:09 Tomek Sowiński wrote: Looks like std.conv.to always allocates behind the scenes. It's a shame as the returned string is immediately processed and discarded in my XML writer. Are there plans to include a custom output variant, e.g. to!string(7, outputRange)? http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 I know about Steven's proposal but it applies only to user types not primitives. Either way std.conv.to would need a buffered output range as integers are written from the right. Any chance for an abstraction analogous to buffered input ranges discussed recently? Generally I found it more difficult to define a solid output buffer abstraction. This is a great motivating example though. To my surprise, an API of the same form seems to be what the doctor prescribed. Here's a semi-formal definition: A buffered output range R is defined as such: R.front returns the currently uncommitted buffer of type T[] R.moreFront(n) makes n more elements available for writing R.commitFront(n) writes the first n elements in front() R.flushFront() writes the buffer currently held in front() and makes another buffer available (initially empty). Andrei
Re: Efficient outputting of to-string conversions
On 2/7/11 7:25 PM, Andrei Alexandrescu wrote: On 2/7/11 5:38 PM, Tomek Sowiński wrote: Jonathan M Davis napisał: On Monday 07 February 2011 13:10:09 Tomek Sowiński wrote: Looks like std.conv.to always allocates behind the scenes. It's a shame as the returned string is immediately processed and discarded in my XML writer. Are there plans to include a custom output variant, e.g. to!string(7, outputRange)? http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 I know about Steven's proposal but it applies only to user types not primitives. Either way std.conv.to would need a buffered output range as integers are written from the right. Any chance for an abstraction analogous to buffered input ranges discussed recently? Generally I found it more difficult to define a solid output buffer abstraction. This is a great motivating example though. To my surprise, an API of the same form seems to be what the doctor prescribed. I meant "of the same form as buffered input ranges". The primitives are similar: expose a buffer, allow it to grow, and discard it progressively. Andrei
Re: Efficient outputting of to-string conversions
On 02/07/2011 11:38 PM, Tomek Sowiński wrote: Jonathan M Davis napisał: On Monday 07 February 2011 13:10:09 Tomek Sowiński wrote: Looks like std.conv.to always allocates behind the scenes. It's a shame as the returned string is immediately processed and discarded in my XML writer. Are there plans to include a custom output variant, e.g. to!string(7, outputRange)? http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 I know about Steven's proposal but it applies only to user types not primitives. Either way std.conv.to would need a buffered output range as integers are written from the right. Any chance for an abstraction analogous to buffered input ranges discussed recently? I haven't read a solution like the proposal for writeTo would not apply to primitives. Is it really so? (If only for language consistency, I would prefere this big shift to apply to all types.) -- _ vita es estrany spir.wikidot.com
Re: Efficient outputting of to-string conversions
On Tuesday 08 February 2011 07:55:23 spir wrote: > On 02/07/2011 11:38 PM, Tomek Sowiński wrote: > > Jonathan M Davis napisał: > >> On Monday 07 February 2011 13:10:09 Tomek Sowiński wrote: > >>> Looks like std.conv.to always allocates behind the scenes. It's a shame > >>> as the returned string is immediately processed and discarded in my > >>> XML writer. Are there plans to include a custom output variant, e.g. > >>> to!string(7, outputRange)? > >> > >> http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 > > > > I know about Steven's proposal but it applies only to user types not > > primitives. Either way std.conv.to would need a buffered output range as > > integers are written from the right. Any chance for an abstraction > > analogous to buffered input ranges discussed recently? > > I haven't read a solution like the proposal for writeTo would not apply to > primitives. Is it really so? (If only for language consistency, I would > prefere this big shift to apply to all types.) Umm. _How_ would it apply to primitives. Does _toString_ apply to primitives? No. toString and writeTo apply to user-defined types that they're defined on. That doesn't mean that we can't or shouldn't find a buffered solution for dealing with primitives and I/O similar to writeTo, but primitives can't have writeTo defined on them any more than they can have toString defined on them. - Jonathan M Davis
Re: Efficient outputting of to-string conversions
On Tue, 08 Feb 2011 10:55:23 -0500, spir wrote: On 02/07/2011 11:38 PM, Tomek Sowiński wrote: Jonathan M Davis napisał: On Monday 07 February 2011 13:10:09 Tomek Sowiński wrote: Looks like std.conv.to always allocates behind the scenes. It's a shame as the returned string is immediately processed and discarded in my XML writer. Are there plans to include a custom output variant, e.g. to!string(7, outputRange)? http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9 I know about Steven's proposal but it applies only to user types not primitives. Either way std.conv.to would need a buffered output range as integers are written from the right. Any chance for an abstraction analogous to buffered input ranges discussed recently? I haven't read a solution like the proposal for writeTo would not apply to primitives. Is it really so? (If only for language consistency, I would prefere this big shift to apply to all types.) writeTo does not need to apply to primitives because primitives can be written to streams without first converting to char[]. For instance, one does not write: writeln(to!string(5)) The whole point of writeTo is to allow easy output of custom data types that the standard library does not know how to output. It was not meant to extend to primitives. As far as Tomek's request, I would expect std.format.formattedWrite(buffer, "%s", 7) to work, or std.format.formatValue (with associated FormatSpec, which I don't feel like looking up the usage of) -Steve
Re: Efficient outputting of to-string conversions
On Tue, 08 Feb 2011 11:09:44 -0500, Steven Schveighoffer
wrote:
On Tue, 08 Feb 2011 10:55:23 -0500, spir wrote:
On 02/07/2011 11:38 PM, Tomek Sowiński wrote:
Jonathan M Davis napisał:
On Monday 07 February 2011 13:10:09 Tomek Sowiński wrote:
Looks like std.conv.to always allocates behind the scenes. It's a
shame as
the returned string is immediately processed and discarded in my XML
writer. Are there plans to include a custom output variant, e.g.
to!string(7, outputRange)?
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9
I know about Steven's proposal but it applies only to user types not
primitives. Either way std.conv.to would need a buffered output range
as integers are written from the right. Any chance for an abstraction
analogous to buffered input ranges discussed recently?
I haven't read a solution like the proposal for writeTo would not apply
to primitives. Is it really so? (If only for language consistency, I
would prefere this big shift to apply to all types.)
writeTo does not need to apply to primitives because primitives can be
written to streams without first converting to char[]. For instance,
one does not write:
writeln(to!string(5))
The whole point of writeTo is to allow easy output of custom data types
that the standard library does not know how to output. It was not meant
to extend to primitives.
As far as Tomek's request, I would expect
std.format.formattedWrite(buffer, "%s", 7) to work, or
std.format.formatValue (with associated FormatSpec, which I don't feel
like looking up the usage of)
BTW, I think we probably should have a formatValue override like this
void formatValue(Char, Writer, T)(Writer w, T t)
{
FormatSpec!Char fs; // use default options
formatValue(w, t, fs);
}
Having to construct a FormatSpec when I just want the default seems like
overkill. Esp. since FormatSpec arg is always ref.
-Steve
Re: Efficient outputting of to-string conversions
Andrei Alexandrescu napisał: > > I know about Steven's proposal but it applies only to user types not > > primitives. Either way std.conv.to would need a buffered output range as > > integers are written from the right. Any chance for an abstraction > > analogous to buffered input ranges discussed recently? > > Generally I found it more difficult to define a solid output buffer > abstraction. This is a great motivating example though. > > To my surprise, an API of the same form seems to be what the doctor > prescribed. Here's a semi-formal definition: > > A buffered output range R is defined as such: > > R.front returns the currently uncommitted buffer of type T[] > > R.moreFront(n) makes n more elements available for writing > > R.commitFront(n) writes the first n elements in front() > > R.flushFront() writes the buffer currently held in front() and makes > another buffer available (initially empty). I was thinking along the same lines. There's one missing: R.skipFront(n) skips the first n elements without outputting Why? Look at integral conversions in std.conv.to. It first calculates maximum string size, then writes numbers to the char array back to front, then returns result[$ - ndigits .. $] where ndigits is how long the string turned out. Returning to Steven's DIP, I think writeTo should take the above rather than void delegate(char[]). With the latter you still have to allocate the pieces. Our buffered output range is friends with polymorphism too. If you set T=char, its API is devoid of generics. Such interface can be placed in object.d with an official blessing. -- Tomek
Re: Efficient outputting of to-string conversions
Andrei Alexandrescu napisał: > For the latter, Tomek's idea of passing an output range as > an optional second parameter seems appropriate. Please file as an > enhancement to bugzilla. If anyone has time to work on this, please do. > If not, I'll work on it as my schedule allows. http://d.puremagic.com/issues/show_bug.cgi?id=5548 -- Tomek
