This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Should _GLIBCXX_DEBUG affect tr1/array?

On Fri, Jan 13, 2012 at 7:43 PM, Christopher Jefferson
<> 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:

#  include<debug/macros.h>

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

(with similar things for operator[] const).

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]