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:
On 03/23/2010 02:45 PM, Fawzi Mohamed wrote:
Andrei, as the topic just came up a comment on the range interface.
Just for plain forward iterators iterators having
bool empty()
E front()
void popFront()
makes the interface non reentrant.
For that purpose having a single function is better.
I use
bool popFront(ref T t)
// returns true if there is a next element, and in that case returns it
in t
this can be used by several consumers concurrently without problems and
creating filters, combiners,... is simple.
Another advantage is that a single object can implement several
iterators.
A disadvantage is that even if there is a single iterator D makes type
inference cumbersome, i.e. you cannot simply use auto, as in a loop you
have to declare the variable before using it as the loop is
T a;
while (it.popFront(a)){
//...
}
We've discussed this extensively, and I lost sleep over this simple
matter more than once. The main problem with bool popFront(ref E) is
that it doesn't work meaningfully for containers that expose
references to their elements.
The interface with front() leaves it to the range to return E or ref E.
An alternative is this:
bool empty();
ref E getNext(); // ref or no ref
I'm thinking seriously of defining input ranges that way. The
underlying notion is that you always move forward - getting an element
is simultaneous with moving to the next.
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).
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.
Andrei
