RFR: 8234779: Provide idiom for declaring classes noncopyable

[Kim Barrett]

> On Nov 28, 2019, at 3:50 AM, Per Liden <per.liden at oracle.com> wrote:
> 
> On 11/27/19 10:49 PM, Kim Barrett wrote:
>> That idiom is rather wordy and indirect though.  In particular, it
>> is generally accompanied by comments indicating that this is to make
>> the class noncopyable, or that the declared functions are not defined
>> (not always with a reason, so that needs to be inferred).  Failure to
>> provide such comments means the reader may need to check for a
>> definition in order to determine whether that idiom is being used, or
>> whether the definitions are just not inline.
>> The proposed macro significantly reduces that wordiness.  Far more
>> importantly, it makes the intent entirely self-evident; there's no
>> need for any explanatory comments.
> 
> My objection is that you are effectively moving us _away_ from a well known C++idiom, since people tend to read code before it goes through the pre-processor. Once we have C++11 support we can easily switch over to using "= delete", and anything that was previously ambiguous or needed a comment will become clear, and our code would stay idiomatic.

Not really.

So far as I can tell, the "well known" and widely used idiom is to
derive from boost::noncopyable or something similar. That's pretty
succinct and to the point. It's the approach I first saw and used in
several other code bases. However, for reasons I mentioned earlier, I
never thought it was a good fit for HotSpot. And having since learned
about the first member problem, I would no longer recommend that
approach at all.

When the declared but undefined, or C++11 deleted mechanisms are
discussed, often they're proposed as a macro, and there are usually
"yuck! macros!" responses to such proposals, often suggesting other
approaches like using a base class.

Whether a macro is used is an interface and ease of use question. I
strongly dislike boilerplate, and this is a fairly extreme example of
such. I also like putting repetitive code behind names to make it
easier to chunk and understand.