On Tue, 23 Mar 2010 16:34:24 -0400, Andrei Alexandrescu
<[email protected]> 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).
-Steve
