RFR: 8234779: Provide idiom for declaring classes noncopyable

[Kim Barrett]

> On Nov 27, 2019, at 3:34 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
> 
> Hi Kim,
> 
> On 2019-11-27 01:18, Kim Barrett wrote:
>> Please review this change that adds a new macro NONCOPYABLE, for
>> declaring a class to be noncopyable.  This change also modifies a
>> bunch of classes to use the new macro.  Most of those classes already
>> included equivalent code, and we're just replacing that with uses of
>> the macro.
> Did you consider doing something like this instead of using this macro?
> [...] snip of NonCopyable class for uses as a private member.

That's a "well known to be problematic" solution.

The NonCopyable member will use additional space in all objects of the
containing class, unless there happens to be an alignment gap it can
be slipped into.  And those are additive if a class contains multiple
noncopyable members.

A NonCopyable base class will sometimes avoid adding space on
platforms that do EBO (Empty Base Optimization).  EBO in such a case
will still be prevented if the first member of the derived class is
similarly derived from NonCopyable.  Requiring a base class for this
feature is also problematic in the face of HotSpot's allocation base
classes and eschewing multiple inheritance.  Also, my recollection is
that multiple inheritance is a case where some platforms are more
likely to fail to do EBO.