Should _GLIBCXX_DEBUG affect tr1/array?

[Jonathan Wakely]

On 16 January 2012 12:28, Edward Rosten wrote:
>
> Presumably it is only constexpr if the argument is also constexpr, in
> which cast it could be checked statically via static_assert?

Nope.  It's always constexpr.


> 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];
>     }

That's not a valid constexpr function.  Among other constraints, for a
function to be constexpr requires that:

its function-body shall be = delete, = default, or a
compound-statement that contains only
— null statements,
— static_assert-declarations
— typedef declarations and alias-declarations that do not define
classes or enumerations,
— using-declarations,
— using-directives,
— and exactly one return statement;


On 16 January 2012 14:03, Edward Rosten wrote:
> Also, I think there is another problem with .at(). Since .at() is
> documented to generate an exception, it is entirely legitimate for
> people to catch those exceptions. If someone was using an array<>
> incorrectly inside a piece of code that catches out_of_range
> exceptions, then in debug mode, the effect of an error in the use of
> array<> would be to trigger a very unexpected code path.

If the operator[] is still noexcept then the exception won't
propagate, it will cause terminate to be called (which will produce a
core dump and stack trace).

Besides, if someone violates a debug mode check their code is already
on an unexpected code path, they're invoked undefined behaviour and
should be happy their computer doesn't catch fire ;-)