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