July 13, 2010 Re: Overhauling the notion of output range | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Mon, 12 Jul 2010 22:58:07 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote: > On 07/12/2010 04:39 PM, Steven Schveighoffer wrote: >> On Mon, 12 Jul 2010 17:25:43 -0400, Andrei Alexandrescu >> <SeeWebsiteForEmail@erdani.org> wrote: >> >>> On 07/12/2010 02:41 PM, Steven Schveighoffer wrote: >>>> I'm unsure how it will work either. I admit now that I didn't think >>>> through how this will be used. >>> >>> It's very simple. As far as a user of an output range is concerned, >>> they should write stuff like: >>> >>> put(r, '['); >>> char[] someBuf; >>> put(r, someBuf); >>> put(r, ", "); >>> put(r, ']'); >>> >>> in confidence that things are reasonably efficient. >> >> How does that work for a range whose front() can be assigned a dchar? >> Wait, it doesn't, because it won't compile. >> >> But wouldn't that be the same for a delegate that takes a dchar? >> >> I'm very confused at what you are trying to do. I expected that a char[] >> would be a valid output range. > > Actually a char[] is not a valid output range. Overwriting variable-length codes with other variable-length codes might mess up the string. Hm... I think it should be, and here is why. Imagine this situation: char[1024] buffer = void; // allocate some blank space on the stack put(buffer, someInputRange); But the above won't compile anyways, because a ref char[1024] isn't a range, and even if it was, it would be left in a state where it pointed to the uninitialized data. What we need is a helper struct, and then we are covered. char[1024] buffer = void; CharBuilder builder(buffer[]); // defines put put(builder, someInputRange); So I think we are good. Does Appender work here? > > Here's what I have. Works? > > void put(R, E)(ref R r, E e) > { > static if (!isArray!R && is(typeof(r.put(e)))) > { > r.put(e); > } > else static if (!isArray!R && is(typeof(r.put((&e)[0..1])))) > { > r.put((&e)[0..1]); > } > else static if (is(typeof(r.front = e, r.popFront()))) > { > r.front = e; > r.popFront(); > } > else static if (isInputRange!E && is(typeof(put(r, e.front)))) > { > for (; !e.empty; e.popFront()) put(r, e.front); > } > else static if (is(typeof(r(e)))) > { > r(e); > } > else static if (is(typeof(r((&e)[0..1])))) > { > r((&e)[0..1]); > } > else > { > static assert(false, "Cannot put a "~E.stringof~" into a "~R.stringof); > } > } That is satisfactory, it encompasses what I was saying, thanks! -Steve |
July 13, 2010 Re: Overhauling the notion of output range | ||||
---|---|---|---|---|
| ||||
Posted in reply to Philippe Sigaud | On Tue, 13 Jul 2010 01:52:52 -0400, Philippe Sigaud <philippe.sigaud@gmail.com> wrote:
> You call r(e) and r([e])) 'delegates'. Are you just using it as a generic
> term, or does that mean using any callable (struct with opCall) is not a
> good idea in this case, for whatever reason?
I think struct with opCall is ok. That's pretty much all a delegate is anyways.
-Steve
|
July 13, 2010 Re: Overhauling the notion of output range | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On 07/13/2010 06:15 AM, Steven Schveighoffer wrote:
> On Mon, 12 Jul 2010 22:58:07 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>> Actually a char[] is not a valid output range. Overwriting
>> variable-length codes with other variable-length codes might mess up
>> the string.
>
> Hm... I think it should be, and here is why. Imagine this situation:
>
> char[1024] buffer = void; // allocate some blank space on the stack
> put(buffer, someInputRange);
>
> But the above won't compile anyways, because a ref char[1024] isn't a
> range, and even if it was, it would be left in a state where it pointed
> to the uninitialized data. What we need is a helper struct, and then we
> are covered.
>
> char[1024] buffer = void;
> CharBuilder builder(buffer[]); // defines put
> put(builder, someInputRange);
>
> So I think we are good. Does Appender work here?
Appender doesn't currently work with fixed-size buffers, but it could and should be made to work. It's a good idea.
Andrei
|
July 13, 2010 Re: Overhauling the notion of output range | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On 07/13/2010 06:18 AM, Steven Schveighoffer wrote:
> On Tue, 13 Jul 2010 01:52:52 -0400, Philippe Sigaud
> <philippe.sigaud@gmail.com> wrote:
>
>> You call r(e) and r([e])) 'delegates'. Are you just using it as a generic
>> term, or does that mean using any callable (struct with opCall) is not a
>> good idea in this case, for whatever reason?
>
> I think struct with opCall is ok. That's pretty much all a delegate is
> anyways.
Yes, the delegate is mostly used as an example. Any syntactically valid r(e) should be accepted.
Andrei
|
Copyright © 1999-2021 by the D Language Foundation