On Tue, 25 Mar 2014 23:22:18 -0000, Walter Bright <[email protected]> wrote:
On 3/25/2014 2:29 PM, Andrei Alexandrescu wrote:
The range instance gets bigger and
more expensive to copy, and the cost of manipulating the flag and the
buffer is added to every loop iteration. Note that the user of a range
can trivially use:
      auto e = r.front;
      ... using e multiple times ...
instead.

That would pessimize code using arrays of large structs.

You're already requiring copying with the buffering requirement. And besides, if I was creating a range of expensive-to-copy objects, I would add a layer of indirection to cheapen it.

Surely you'd simply start with a range of pointers to expensive-to-copy objects? Or, return them by reference from the underlying range/array/source. You want to avoid *ever* copying them except explicitly where required.

The proposed protocol pessimizes arrays of large structs

Not really more than the existing protocol does (i.e. required buffering).

and will trip the unwary if calling r.front again returns something else.

I'm not proposing that calling them wrongly would make things unsafe. But I don't think it's unreasonable to expect the protocol to be followed, just like file open/read/close.

My immediate expectation upon encountering ranges was that r.front would return the same item repeatedly until r.popFront was called. Breaking that guarantee will trip a *lot* of people up.

IMO the rules should be something like:
 - r.empty WILL return false if there is more data available in the range.

- r.empty MUST be called before r.front, r.front WILL succeed if r.empty returned false. - r.front WILL repeatably return the current element in the range. It MAY return by value or by reference.

- r.empty SHOULD be called before r.popFront, otherwise r.popFront MAY do nothing or throw
   (could also make this one a 'MUST')
 - r.popFront WILL advance to the next element in the range.

 - "lazy" ranges SHOULD delay initialisation until r.empty is called

R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

Reply via email to