Should _GLIBCXX_DEBUG affect tr1/array?

[Edward Rosten]

On Fri, Jan 13, 2012 at 7:43 PM, Christopher Jefferson
<caj21@st-andrews.ac.uk> wrote:

>>
>> Patches welcome :)
>
> The patch actually got slightly more interesting, as the operator[] const is both constexpr and noexcept. The standard doesn't require it, but they are nice additions.  In particular constexpr prevents the use of the normal debug-mode stuff.

Presumably it is only constexpr if the argument is also constexpr, in
which cast it could be checked statically via static_assert?

I haven't looked into constexpr in detail though.

> After poking a few attempts, my current best implementation is actually to just use the same implementation as 'at()', throwing if an error occurs, and then let the noexcept's terminate kill the program, so something like:
>
> return __n < _Nm ?
>               _M_instance[__n] : throw out_of_range(__N("Array operator[] out of bounds"));
>
> Wrapped approriately in #ifdef _GLIBCXX_DEBUG, and #ifdef EXCEPTIONS. This would make it an oddity with respect to the other tests, not producing such a nice message (the message could obviously be made to look a bit more standard).
>
> Comments?

I've been reading through some of the libstdc++ headers to try to
determine the correct way to do this.

it like a good way might be to have:

#ifdef _GLIBCXX_DEBUG
#  include<debug/macros.h>
#endif

Then, operator[] would become:
     // Element access.
     reference
     operator[](size_type __n)
     {
        #ifdef _GLIBCXX_DEBUG
          __glibcxx_check_subscript(__n);
        #endif
        return _M_instance[__n];
     }

(with similar things for operator[] const).

This would give the same kind of error messages as other subscript checks.

-Ed