Re: [boost] [xpressive] Performance Tuning?

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