Ranges and/versus iterators

Fawzi Mohamed fawzi at gmx.ch
Tue Mar 23 15:56:22 PDT 2010


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
>> <SeeWebsiteForEmail at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20100323/e1a1e884/attachment.html>


More information about the Digitalmars-d mailing list