Ranges and/versus iterators

[Andrei Alexandrescu]

On 03/23/2010 09:12 PM, Steven Schveighoffer wrote:
> Andrei Alexandrescu Wrote:
>
>> On 03/23/2010 03:46 PM, Steven Schveighoffer 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).
>>
>> 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.
>
> First, a range backed by getchar is about as useful as functional qsort ;)

Actually I need one. Think fscanf, i.e. unformat() for streams.

Andrei