RFR: 8234779: Provide idiom for declaring classes noncopyable

[Kim Barrett]

> On Nov 29, 2019, at 6:04 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Nov 27, 2019, at 1:49 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> 
>> 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.
> 
> Or to put it another way, the explanatory comments can be centralized
> in the header file which defines the macro.  And the macro can be given
> a name which explains the intent.  The name and comments can reflect
> HotSpot-specific “house rules” (local design rules and conventions).
> 
> On Nov 29, 2019, at 1:45 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> … I also like putting repetitive code behind names to make it
>> easier to chunk and understand.
> 
> +1  A well-chosen macro name can be easier to read than a chunk of boilerplate.
> This is especially applicable to us since C++ boilerplate evolves over time, and
> as a highly portable system we don’t have the ability to track one particular
> dialect of C++.  But even if we did, we'd still have complex “house rules” to
> enforce and document, and macros play a role there.
> 
> I don’t think that learning the “house macros” for HotSpot is an excessive
> burden for people learning to work on HotSpot.  Kim’s proposal seems to
> be yet another one of these macros.
> 
> Thanks, Kim and Per, for marshaling the arguments pro and con.
> 
> — John

Thanks John.

I've also decided to take your earlier advice (from off-list) to use
an external terminating semicolon, rather than having it in the macro
expansion (webrev updated in place). Besides potentially helping
editors indent properly (which is not a problem for at least some
editors), some uses looked very odd in context without a trailing
semicolon. (The location of the terminating semicolon is rendered moot
by C++11, but I can't prove all compilers currently used to build JDK
support empty declarations in classes.) While I prefer macros whose
expansions are "complete" (where that makes sense for the macro),
that's not a strong preference.