Should _GLIBCXX_DEBUG affect tr1/array?

[Christopher Jefferson]

On 13 Jan 2012, at 12:40, Edward Rosten wrote:

> Should the _GLIBCXX_DEBUG macro affect the operation of
> std::tr1::array? At the moment it has no effect (I assumed it had and
> chased my tail for a while).
> 
> The following code:
> 
> #define _GLIBCXX_DEBUG
> #include <vector>
> #include <tr1/array>
> #include <iostream>
> using namespace std;
> 
> int main()
> {
> 	tr1::array<int, 10> a;
> 	a[11] = 0;
> 
> 	cerr << "Array OK\n";
> 
> 	vector<int> b(10);
> 	b[11] = 0;
> 	cerr << "Vector OK\n";
> }
> 
> Produces the output:
> 
> Array OK
> /usr/include/c++/4.6/debug/vector:313:error: attempt to subscript container
>    with out-of-bounds index 11, but container only holds 10 elements.
> 
> Objects involved in the operation:
> sequence "this" @ 0x0x7fff001872e0 {
>  type = NSt7__debug6vectorIiSaIiEEE;
> }
> Aborted
> 
> Is this a bug?
> 
> I'm using Ubuntu 11.10's default install of gcc 4.6.1

I literally had the same problem just today. adding a check to operator[] would seem like an easy addition, and would catch many issues.

In principle, full iterator checking could also be added, as the C++ standard does say the type of array::iterator is implementation defined.  However, array has to be an aggregate type, and I'm not sure if adding more members (to handle iterator checks) could lead to breaking code which uses array.

Chris