Jonathan M Davis Wrote:
> On Thursday, August 26, 2010 10:51:02 Andrei Alexandrescu
> wrote:
[...]
> > I'm weary of this philosophy. I've seen a phenomenon happen
> > time and again with myself and others: you hit a 10% case
> > exactly when you (a) know what you want to do, (b) you
> > know tha
On Thursday, August 26, 2010 10:51:02 Andrei Alexandrescu wrote:
> On 8/26/10 9:18 PDT, dsimcha wrote:
> > I'm starting to think that the whole concept of ranges is starting to get
> > too complicated. We're already seeing it with this moveFront() stuff
> > that's a special case to deal with struc
On Thu, 26 Aug 2010 13:30:35 -0400, Pillsy wrote:
Steven Schveighoffer Wrote:
On Thu, 26 Aug 2010 11:17:32 -0400, Pillsy
wrote:
[...]
> If you don't mind me asking, what made you give up on it?
A cursor that refers to one element is much more efficient to pass
around/copy.
Ah, yes. If
On 8/26/10 9:18 PDT, dsimcha wrote:
I'm starting to think that the whole concept of ranges is starting to get too
complicated. We're already seeing it with this moveFront() stuff that's a
special
case to deal with structs that have expensive postblits. We need a healthy dose
of "worse is bette
On 8/26/10 7:18 PDT, Pillsy wrote:
[snip]
Range before ();
Range after ();
(I wrote my last post before reading yours.) Excellent points. I do
think we can get away without defining a new type. In addition to the
allBefore(all, tail) primitive (which is easy to implement as a saf
Steven Schveighoffer Wrote:
> On Thu, 26 Aug 2010 11:17:32 -0400, Pillsy
> wrote:
[...]
> > If you don't mind me asking, what made you give up on it?
> A cursor that refers to one element is much more efficient to pass
> around/copy.
Ah, yes. If you just need the one element, I figure that
== Quote from Pillsy (pillsb...@gmail.com)'s article
> These thoughts were inspired by the recent thread, "Retrieving the
> traversed range". I am generally pretty sold on the range concept,
> but I think for some operations some sort of cursor is required.
> However, there are some unsafe cursor-r
On Thu, 26 Aug 2010 11:17:32 -0400, Pillsy wrote:
Steven Schveighoffer Wrote:
On Thu, 26 Aug 2010 10:18:51 -0400, Pillsy
wrote:
[...]
> The key idea is that these cursors aren't a primitive part of a
> range; instead, they take a range and add a position *inside*
> the range. They're a per
Steven Schveighoffer Wrote:
> On Thu, 26 Aug 2010 10:18:51 -0400, Pillsy
> wrote:
[...]
> > The key idea is that these cursors aren't a primitive part of a
> > range; instead, they take a range and add a position *inside*
> > the range. They're a perfect fit for all those "three-legged"
> > op
On Thu, 26 Aug 2010 10:18:51 -0400, Pillsy wrote:
These thoughts were inspired by the recent thread, "Retrieving the
traversed range". I am generally pretty sold on the range concept,
but I think for some operations some sort of cursor is required.
However, there are some unsafe cursor-related
These thoughts were inspired by the recent thread, "Retrieving the
traversed range". I am generally pretty sold on the range concept,
but I think for some operations some sort of cursor is required.
However, there are some unsafe cursor-related operations that are
best avoided.
However, as far
11 matches
Mail list logo
