Updated to fix the copyright start date and include guard name, and to document the class. I also added another comment to explain how it works.

While documenting this, I realized that it additionally happens to prevent the implicit default definition of the move constructor and move assignment operator (in both Uncopyable itself and then therefore in its subtypes). I think moves usually make sense for a type even if copies don't. This could easily be made movable and therefore allow its subtypes to implicitly define move operations like so:

Uncopyable(Uncopyable&&) {}
Uncopyable &operator=(Uncopyable&&) { return *this; }

However, it isn't clear that we have a reasonable level of support for move semantics in all of our build compilers (even though the list of supported C++ features claims that we can use it). For example, cppreference.com says that no version of XLC++ supports "defaulted move special member functions." From a bit of experimentation, it seems that this includes implicitly-defined move operations, which means that we couldn't portably rely on the implicit definitions allowed by the snippet above.

But it seems we don't use move semantics regardless. At least, I don't recall seeing any explicit rvalue references or moves in the codebase, and in my experimentation I hit a number of surprising road blocks beyond just the lack of defaulted move methods, e.g. lack of move constructors for STL types. So for now I've left the move constructor and assignment operator undeclared without so much as commenting about them in the code, just as though move semantics don't even exist.

Jenkins build all