Re: noexcept
On 27 Apr., 22:02, Marc wrote:
the definition of the noexcept operator seems to imply that any call
to a function not explicitly marked as noexcept makes it answer false.
No, this is not 100% correct. The definition refers to "non-throwing
exception specifications". This includes noexcept, noexcept(true) as
well as throw().
In particular, that would mean that
is_nothrow_copy_constructible < some_POD_type > :: value == false.
Or if I missed a paragraph about that, at least:
void f(){}
assert(noexcept(f())==false);
I don't know about the POD copy constructor (maybe it's implicitly
defined as noexcept?) but the assertion of yours about f should hold
as far as I can tell. I believe, anything else would get messy in case
declarations and definitions of functions are separated into different
translation units.
Is that really the case? Any reason the compiler is forbidden from
proving that f() can't throw when it has the definition at hand?
Compiler complexity and inconsistent results. What if you declare such
a function in a header and use the same "noexcept expression" in
another translation unit without having the definition available? I'd
be very much against inconsistent results for the _same_ function
across different TUs.
Also, there are many is_nothrow_* helpers, but not
is_nothrow_swappable. Is it because
noexcept(swap(declval<T&>(),declval<T&>())) is sufficient
Is it sufficient? --- Oh yes, it seems it is, since std::swap uses a
conditional noexcept specification.
(several of
the is_nothrow_* helpers seem to have subtleties for arrays of void
that prevent them from being equivalent to a simple noexcept
expression)? I have types that can be move-assigned or swapped without
throwing but for which any constructor may throw, and I fear they will
miss on many optimizations.
Hmm... that sounds odd. Can you give an example for one of these
types? I have some trouble imagining why swapping should be any
"easier" w.r.t. exception safety than move construction.
Cheers!
SG