This is the mail archive of the libstdc++@gcc.gnu.org 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 Mon, Jan 16, 2012 at 2:29 PM, Christopher Jefferson
<caj21@st-andrews.ac.uk> wrote:

>> I haven't looked into constexpr in detail though.
>
> You unfortunatly can't overload on constexpr. Therefore if you want a constexpr operator[], you only get a constexpr operator[]. Your example below fails to be 'constexpr' for various reasons.
>
> Providing a non-constexpr debugging operator[] seems like a bad idea, because then people who write code which relies on the constexpr operator[] won't be able to run it in debug mode (and if we don't want to allow them to use the constexpr operator[], why bother defining it that way?)
>
> Re-thinking this, I think there is an easy implementation, which gets most of what we want, which is to just to make operator[] call 'at' in debug mode.

I'm not sure I follow. Wouldn't using .at() also prevent the debug
mode version from being constexpr?

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.

I think the advantage of using __glibcxx_check_subscript is that it
also produces a very recognisable error message.

-Ed


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