Boost logo

Boost :

Subject: Re: [boost] [xpressive] Performance Tuning?
From: Edward Grace (ej.grace_at_[hidden])
Date: 2009-07-22 05:29:06


On 21 Jul 2009, at 13:42, Celtic Minstrel wrote:

> On Tue, Jul 21, 2009 at 6:17 AM, Edward
> Grace<ej.grace_at_[hidden]> wrote:
>> // Will the following fail? It jolly well should!
>> v[5] = 2;
>> cout << v.capacity() << " " << v.size() << endl;
>
>> That's pure evil of course! I suppose that's a good reason for
>> always using
>> .begin() and .end() rather than .begin() + N.
>
> Correct me if I'm wrong, but it seems you're complaining that v[5]
> doesn't do bounds checking?

Not really. Perhaps 'fail' in the above is not quite what I mean. My
main gripe is the inconsistency.

> The standard does not require bounds checking on array subscript,
> though it seems there's
> nothing saying it shouldn't bounds check. But there's the alternate
> v.at(5) notation if you do need
> bounds checking.

My problem is really that this is 'undefined' behaviour. Surely
anything that's 'undefined' is open to error?

My second gripe is that even the idea of undefined behaviour is
inconsistent (in MSVC at least). I can quite happily iterate
something to .end() (one past the last element) but not to .end()+n
--- why? From what I understand dereferencing either is wrong, why
is one more wrong than the other?

 From what I can see this prevents the simple creation of a striding
iterator, for which the .end() can be at .end() + stride of the
underlying vector. One can do it easily by default in g++ as it
doesn't hold your hand (exposing you to dereferincing this as being
undefined) and leaving that up to you. In MSVC8 it will barf since
the debug bounds checking doesn't allow you to keep iterating past
the end.

Which is the correct treatment?

-ed


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk