While I can’t see much of a question in there except “Has anyone ever needed placement new to correctly handle the null pointer case?” (I haven’t), I think the case is interesting enough to spill some thoughts on the issue. I consider the standard broken or incomplete wrt the placement new function and requirements to … Read more
No this can not be the case, because not every inovocation of constexpr function has to be able to be evaluated as subexpression of a core constant expression. We only need one argument value that allows for this. So a constexpr function can contain a throw statement as long as we have a argument value … Read more
I think I would move it into a separate namespace namespace tricks { using std::swap; template <typename T, typename U> void swap(T &t, U &u) noexcept(noexcept(swap(t, u))); } template <typename T> void swap(my_template<T>& x, my_template<T>& y) noexcept(noexcept(tricks::swap(std::declval<T>(), std::declval<T>()))) { using std::swap; swap(x.something_that_is_a_T, y.something_that_is_a_T); } Alternatively you can move the whole code up into tricks and … Read more
There’s “no” overhead and then there’s no overhead. You can think of the compiler in different ways: It generates a program which performs certain actions. It generates a program satisfying certain constraints. The TR says there’s no overhead in the table-driven appraoch because no action needs to be taken as long as a throw doesn’t … Read more
Use a macro #ifndef _MSC_VER #define NOEXCEPT noexcept #else #define NOEXCEPT #endif And then define the function as virtual const char* what() const NOEXCEPT override You could also modify that to allow noexcept on later versions of VS by checking the value of _MSC_VER; for VS2012 the value is 1600.
The standard’s policy on noexcept is to only mark functions that cannot or must not fail, but not those that simply are specified not to throw exceptions. In other words, all functions that have a limited domain (pass the wrong arguments and you get undefined behavior) are not noexcept, even when they are not specified … Read more
Exception specifiers were deprecated because exception specifiers are generally a terrible idea. noexcept was added because it’s the one reasonably useful use of an exception specifier: knowing when a function won’t throw an exception. Thus it becomes a binary choice: functions that will throw and functions that won’t throw. noexcept was added rather than just … Read more
I think it is too early to give a “best practices” answer for this as there hasn’t been enough time to use it in practice. If this was asked about throw specifiers right after they came out then the answers would be very different to now. Having to think about whether or not I need … Read more