On Wed, 26 Mar 2014 17:32:30 -0000, monarch_dodra <[email protected]>
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/
