exception-specification

Consider these two possible definitions for a class: Exhibit A: struct A { A() = delete; }; Exhibit A′: struct A { A() noexcept = delete; } Is there any point in declaring a deleted function as noexcept ? (Posted this initially as a comment, but encouraged to post as an answer.) Simply, no. A function that is deleted cannot be called (or, in the case of a constructor, used to initialise an object) let alone throw an exception. Edit: hvd mentioned in comments below that noexcept(f()) does not call f() . If the constructor of class A is delete d, then noexcept(A()) will fail to compile,

I have seen problems when using C++ code that, unexpectedly to the caller, throws an exception. It's not always possible or practical to read every line of a module that you are using to see if it throws exceptions and if so, what type of exception. Are there established idioms or "best practices" that exist for dealing with this problem? I've thought of the following: In our doxygen documentation, we could add a comment in every function that is expected to throw an exception and it's type(s). Pluses: Simple. Minuses: Subject to user error. We could have an app-wide try/catch(...) for safety.

I've been using Howard Hinnant's stack allocator and it works like a charm, but some details of the implementation are a little unclear to me. Why are global operators new and delete used? The allocate() and deallocate() member functions use ::operator new and ::operator delete respectively. Similarly, the member function construct() uses the global placement new. Why not allow for any user-defined global or class-specific overloads? Why is alignment set to hard-coded 16 bytes instead of std::alignment_of<T> ? Why do the constructors and max_size have a throw() exception specification? Isn't