On 07/13/2010 06:15 AM, Steven Schveighoffer wrote:
On Mon, 12 Jul 2010 22:58:07 -0400, Andrei Alexandrescu
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 i
On 07/13/2010 06:18 AM, Steven Schveighoffer wrote:
On Tue, 13 Jul 2010 01:52:52 -0400, Philippe Sigaud
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
On Tue, 13 Jul 2010 01:52:52 -0400, Philippe Sigaud
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'
On Mon, 12 Jul 2010 22:58:07 -0400, Andrei Alexandrescu
wrote:
On 07/12/2010 04:39 PM, Steven Schveighoffer wrote:
On Mon, 12 Jul 2010 17:25:43 -0400, Andrei Alexandrescu
wrote:
On 07/12/2010 02:41 PM, Steven Schveighoffer wrote:
I'm unsure how it will work either. I admit now that I did
On Tue, Jul 13, 2010 at 05:18, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:
To clarify:
http://erdani.com/d/phobos/std_range.html
Seems good to me. Lots of flexibility. I may begin to write output ranges
:-)
So in the very first case, e may well be a range, but the way
On 07/12/2010 09:58 PM, Andrei Alexandrescu wrote:
Here's what I have. Works?
[snip]
To clarify:
http://erdani.com/d/phobos/std_range.html
Andrei
On 07/12/2010 04:39 PM, Steven Schveighoffer wrote:
On Mon, 12 Jul 2010 17:25:43 -0400, Andrei Alexandrescu
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
On 07/12/2010 04:39 PM, Steven Schveighoffer wrote:
On Mon, 12 Jul 2010 17:25:43 -0400, Andrei Alexandrescu
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
On Mon, 12 Jul 2010 17:25:43 -0400, Andrei Alexandrescu
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
s
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
On 12/07/2010 03:17, Andrei Alexandrescu wrote:
he notion of output range has been a tad vague in the past; up until now
a range that wanted to qualify as an output range had to define a method
called put.
What if we have to deal with non orthogonal structures, or .. simple
directed graphs ?
On 2010-07-12 13:49:50 -0400, Andrei Alexandrescu
said:
The point is that with a delegate you must choose between accepting E
and E[]. Given the constraint, it's better for everyone to accept E[]
and let put() take care of the occasional E by doing the wraparoo
(&elem)[0..1].
If this means
On Mon, 12 Jul 2010 15:18:17 -0400, Andrei Alexandrescu
wrote:
On 07/12/2010 01:47 PM, Steven Schveighoffer wrote:
On Mon, 12 Jul 2010 13:49:50 -0400, Andrei Alexandrescu
wrote:
Yes. The point is that with a delegate you must choose between
accepting E and E[]. Given the constraint, it's b
On 07/12/2010 01:47 PM, Steven Schveighoffer wrote:
On Mon, 12 Jul 2010 13:49:50 -0400, Andrei Alexandrescu
wrote:
Yes. The point is that with a delegate you must choose between
accepting E and E[]. Given the constraint, it's better for everyone to
accept E[] and let put() take care of the occa
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> On 07/12/2010 01:31 PM, dsimcha wrote:
> > But efficiency only matters some of the time, assuming the kind of
> > inefficiency in
> > question is small constant term inefficiency (as is the case here) and not
> > O(N!)
On 07/12/2010 01:31 PM, dsimcha wrote:
But efficiency only matters some of the time, assuming the kind of inefficiency
in
question is small constant term inefficiency (as is the case here) and not O(N!)
inefficiency or 1000-fold constant term inefficiency.
Historically the constant was large.
Andrei Alexandrescu wrote:
> Yes. The point is that with a delegate you must choose between accepting
> E and E[]. Given the constraint, it's better for everyone to accept E[]
> and let put() take care of the occasional E by doing the wraparoo
> (&elem)[0..1].
I don't think the current implementat
On Mon, 12 Jul 2010 13:49:50 -0400, Andrei Alexandrescu
wrote:
On 07/12/2010 11:48 AM, Steven Schveighoffer wrote:
On Mon, 12 Jul 2010 11:05:33 -0400, Andrei Alexandrescu
wrote:
On 07/12/2010 09:59 AM, Steven Schveighoffer wrote:
If I always have to do something like this in order to app
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> On 07/12/2010 12:55 PM, Steven Schveighoffer wrote:
> > On Mon, 12 Jul 2010 13:43:18 -0400, torhu wrote:
> >
> >> On 12.07.2010 18:48, Steven Schveighoffer wrote:
> >> [...]
> >>> So what happens when you call put(r, e)
On 07/12/2010 12:55 PM, Steven Schveighoffer wrote:
On Mon, 12 Jul 2010 13:43:18 -0400, torhu wrote:
On 12.07.2010 18:48, Steven Schveighoffer wrote:
[...]
So what happens when you call put(r, e) for one of these output
classes? Instead of just calling add(e), it calls (add((&e)[0..1]))
which
On Mon, 12 Jul 2010 13:43:18 -0400, torhu wrote:
On 12.07.2010 18:48, Steven Schveighoffer wrote:
[...]
So what happens when you call put(r, e) for one of these output
classes? Instead of just calling add(e), it calls (add((&e)[0..1]))
which in turn goes through some needless loop, which then
On 07/12/2010 11:48 AM, Steven Schveighoffer wrote:
On Mon, 12 Jul 2010 11:05:33 -0400, Andrei Alexandrescu
wrote:
On 07/12/2010 09:59 AM, Steven Schveighoffer wrote:
If I always have to do something like this in order to append a single
element:
put(r, (&elem)[0..1]);
No, the library does
On 12.07.2010 18:48, Steven Schveighoffer wrote:
[...]
So what happens when you call put(r, e) for one of these output
classes? Instead of just calling add(e), it calls (add((&e)[0..1]))
which in turn goes through some needless loop, which then ends up
calling add(e). I don't see why this is pre
On Mon, 12 Jul 2010 11:05:33 -0400, Andrei Alexandrescu
wrote:
On 07/12/2010 09:59 AM, Steven Schveighoffer wrote:
If I always have to do something like this in order to append a single
element:
put(r, (&elem)[0..1]);
No, the library does that. Look here:
http://www.dsource.org/projects/
On 07/12/2010 09:59 AM, Steven Schveighoffer wrote:
On Mon, 12 Jul 2010 10:41:51 -0400, Andrei Alexandrescu
wrote:
On 07/12/2010 07:44 AM, Steven Schveighoffer wrote:
On Mon, 12 Jul 2010 02:21:25 -0400, Andrei Alexandrescu
wrote:
On 07/12/2010 12:45 AM, Philippe Sigaud wrote:
On Mon, Jul
On Mon, 12 Jul 2010 10:41:51 -0400, Andrei Alexandrescu
wrote:
On 07/12/2010 07:44 AM, Steven Schveighoffer wrote:
On Mon, 12 Jul 2010 02:21:25 -0400, Andrei Alexandrescu
wrote:
On 07/12/2010 12:45 AM, Philippe Sigaud wrote:
On Mon, Jul 12, 2010 at 03:17, Andrei Alexandrescu
mailto:seewe
On 07/12/2010 07:44 AM, Steven Schveighoffer wrote:
On Mon, 12 Jul 2010 02:21:25 -0400, Andrei Alexandrescu
wrote:
On 07/12/2010 12:45 AM, Philippe Sigaud wrote:
On Mon, Jul 12, 2010 at 03:17, Andrei Alexandrescu
mailto:seewebsiteforem...@erdani.org>>
wrote:
In related news, there's been thi
On Mon, 12 Jul 2010 02:21:25 -0400, Andrei Alexandrescu
wrote:
On 07/12/2010 12:45 AM, Philippe Sigaud wrote:
On Mon, Jul 12, 2010 at 03:17, Andrei Alexandrescu
mailto:seewebsiteforem...@erdani.org>>
wrote:
In related news, there's been this burning desire regarding a
lightweight ou
On 07/12/2010 12:45 AM, Philippe Sigaud wrote:
On Mon, Jul 12, 2010 at 03:17, Andrei Alexandrescu
mailto:seewebsiteforem...@erdani.org>>
wrote:
In related news, there's been this burning desire regarding a
lightweight output range defined as simply a delegate that accepts
const(char)
On Mon, Jul 12, 2010 at 03:17, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:
> In related news, there's been this burning desire regarding a lightweight
> output range defined as simply a delegate that accepts const(char)[]. That
> range is an output range all right, and the way you
On 07/11/2010 08:34 PM, dsimcha wrote:
1. What happens if you run out of space in the input range variety? I guess it
throws?
It's up to the range. Most will throw.
2. Would there be a "standard" way of signaling how much stuff was written to
the
input range variety? I guess that since f
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> The notion of output range has been a tad vague in the past; up until
> now a range that wanted to qualify as an output range had to define a
> method called put.
> That definition is awkward though. For example, the std.
On 07/11/2010 08:17 PM, Andrei Alexandrescu wrote:
[snip]
Forgot to mention one detail: now the free function std.range.put()
serves as a convenient dispatcher for any kind of output range.
Andrei
The notion of output range has been a tad vague in the past; up until
now a range that wanted to qualify as an output range had to define a
method called put.
That definition is awkward though. For example, the std.algorithm.copy()
primitive should work for an output range, but also for some o
34 matches
Mail list logo
