protocol for using InputRanges

Regan Heath regan at netmail.co.nz
Wed Mar 26 11:12:11 PDT 2014


On Wed, 26 Mar 2014 17:32:30 -0000, monarch_dodra <monarchdodra at gmail.com>  
wrote:

> On Wednesday, 26 March 2014 at 16:55:48 UTC, Regan Heath wrote:
>> On Wed, 26 Mar 2014 16:38:57 -0000, monarch_dodra
>>> Not only that, but it's also a performance criteria: If you are  
>>> iterating on two ranges at once (think "copy"), then you *know*  
>>> "range2" is longer than "range1", even if you don't know its length.
>>
>> What guarantees range2 is longer than range1?  The isArray case checks  
>> explicitly, but the generic one doesn't.  Is it a property of being an  
>> output range that it will expand as required, or..
>
> The interface: The target *shall* have enough room to accommodate  
> origin. Failure to meet that criteria is an Error.

Ok.  So long as *something* is throwing that Error I am down with this.

> Output ranges may or may not auto expand as required. Arguably, it's a  
> design flaw I don't want to get started on.

:)

>>> Why pay for "range2.empty", when you know it'll always be false? There  
>>> is a noticeable performance difference if you *don't* check.
>>
>> But aren't you instead paying for 2 checks in front and 2 in popFront,  
>> so 4 checks vs 1?  Or is the argument that these 4 checks cannot be  
>> removed even if we mandate r.empty is called before r.front/popFront.
>
> I don't know what checks you are talking about. Most ranges don't check  
> anything on front or popFront. They merely assume they are in a state  
> that where they can do their job. Failure to meet this condition prior  
> to the call (note I didn't say "failure to check for"), means Error.

Ok.. but lets take a naive range of say int with a 1 element cache in the  
member variable "int cache;".  The simplest possible front would just be  
"return cache;".  But, if cache hasn't been populated yet it's not going  
to throw an Error, it's just going to be wrong.

So, presumably front has to check another boolean to verify it's been  
populated and throw an Error if not.  That's one of the checks I meant.  A  
typical loop over a range will call front one or more times, so you pay  
for that check 1 or more times per loop.

popFront in this example doesn't need to check anything, it just populates  
cache regardless, as does empty.

But, I imagine there are ranges which need some initial setup, and they  
have to do it somewhere, and they need to check they have done it in  
empty, front and popFront for every call.  It's those checks we'd like to  
avoid if we can.

So.. if we mandate that empty MUST be called, then they could just be done  
in one place, empty.

However, in this situation nothing would be enforcing that requirement (in  
release anyway) and things could just go wrong.  So, perhaps the checks  
always need to be there and we gain nothing by mandating empty is called  
first.

idunno.

> It's really not much different from when doing an strcpy. "++p" and "*p"  
> don't check anything. The fact that ranges *can* check doesn't always  
> mean they should.

Sure.  For performance reasons they might not, but isn't this just a tiny  
bit safer if we mandate empty must be called and do one check there..

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/


More information about the Digitalmars-d mailing list