This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] constexpr array additions
- From: François Dumont <francois dot cppdevs at free dot fr>
- To: libstdc++ at gcc dot gnu dot org
- Date: Fri, 22 Jul 2011 22:42:37 +0200
- Subject: Re: [v3] constexpr array additions
- References: <20110720214323.0d0d8a3e@shotwell>
On 07/21/2011 06:43 AM, Benjamin Kosnik wrote:
Also pointed out by Daniel.
It's kind of hokey to work around -fno-exceptions like this, but seems
harmless. In this particular case, deferring the throw to a function
like __throw_out_of_range makes the ::at member an invalid constant
expression.
Yay! std::array with compile time operator []!
tested x86/linux
-benjamin
- const_reference
+ constexpr const_reference
at(size_type __n) const
{
- if (__n>= _Nm)
- std::__throw_out_of_range(__N("array::at"));
- return _M_instance[__n];
+ return __n< _Nm ? _M_instance[__n] :
+#ifdef __EXCEPTIONS
+ throw out_of_range(__N("array::at"));
+#else
+ _M_instance[0];
+#endif
Why returning _M_instance[0] if __n is invalid ? This is the best way to hide an issue under the carpet. I know that calling std::abort is not valid within a constexpr but returning a potentially valid instance will hide the problem, returning _M_instance[__n] have more chance to make the code break quickly.
IMO the whole 'at' method should be hidden without exception support if we can't substitute with std;;abort. This method is completely based on exception support and if some code is using it it means that it expects exception support, without it it should not compile anymore. An other option is to make the method constexpr only when there is exception support.
François