On 23-mar-10, at 21:51, Andrei Alexandrescu wrote:
On 03/23/2010 03:46 PM, Steven Schveighoffer wrote:
On Tue, 23 Mar 2010 16:34:24 -0400, Andrei Alexandrescu
<[email protected]> wrote:
[...]
A while back, you identified one of the best interfaces for input
ranges:
E* getNext();
Which allows for null returns when no data is left. The drawback is
that
E must be either referenced or allocated on the heap (providing
storage
to the function is an option). But the killer issue was that safeD
would
not allow it. However, in recent times, you have hinted that safeD
may
allow pointers, but disallow bad pointer operations. In light of
this,
can we reconsider this interface, or other alternatives using
pointers?
I've always felt that if we were to define ranges for streams in a
non-awkward way, we would need an "all in one" operation, since not
only
does getting data from the range move the range, but checking for
empty
might also move the range (empty on a stream means you tried to
read and
got nothing).
yes that also makes filters/combiners really nice to write.
the basic thing is that you have to return two things, 1. if there is
more and 2. if yes the element.
I'd gladly reconsider E* getNext(), and I like it a lot, but that
doesn't accommodate ranges that want to return rvalues without
storing them (e.g. a range using getchar() as a back-end, and
generally streams that don't correspond to stuff stored in memory).
If it's not in memory, there's no pointer to it.
E* getNext would probably also be workable, at the cost of storing one
element. But then as andrei correctly points out one still cannot
expect the pointer to be valid after one iteration, so as soon as you
don't have memory storage you loose thread safety...
Now reentrancy/thread safety is not necessarily the most important
thing for iterators, but I like that my queues, sources of work can
have the same interface.
