Accessors, byLine, input ranges

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Fri Jan 29 10:47:52 PST 2010


Michel Fortin wrote:
> On 2010-01-29 12:53:27 -0500, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> said:
> 
>> An algorithm can fail in many silent ways if it misuses the range 
>> interface. None of std.algorithm algorithms uses front naively.
> 
> Easy to say. How did you verify that?

It's simply a mistake I make very seldom if at all (I don't remember any 
instance). The range interface is narrow, and algorithms are always 
careful with how they use it.

> The problem is very subtle: if you call front after popFront on 
> something like byLine which adds a buffer on top of another range, it'll 
> eat one or more element on the downstream range that will be lost if you 
> dispose of the filtering range. It won't have any effect on algorithms 
> using the filtering range in itself, only on those using both the 
> filtering range and the downstream range in tandem.

Subtle problems could occur with a variety of other ranges if some 
algorithm messes them up.

> So basically, if you have an algorithm that calls front after popFront, 
> that algorithm cannot be used reliably for ranges filtering a stream 
> when that stream is also used directly, or used via other filtering 
> ranges. There's no way to enforce that as it becomes the user's problem.
> 
> Whereas if input ranges only define 'take', it's pretty easy for the 
> compiler to tell you an algorithm needs a buffer, so you add an 
> intermediary buffer range yourself and you're now aware of the 
> consequences.

I like take (I actually called it getNext). There was just too much 
aggravation in defining and using that interface. I've literally lost 
nights over figuring it out, and couldn't. Searching for getNext on this 
group will reveal some of the issues.


Andrei



More information about the Digitalmars-d mailing list