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
<seewebsiteforem...@erdani.org> 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.

Reply via email to