RFR: 8234779: Provide idiom for declaring classes noncopyable

[Per Liden]

Hi Kim & John,

On 12/2/19 12:10 AM, Kim Barrett wrote:
>> 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.

It seems I'm not going to convince anyone, so let's just agree to 
disagree. I withdraw my objection.

>>
>> — 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

+1. An external semicolon makes it look less foreign.

I'd also like to suggest that this type of macro belongs in 
globalDefinitions.hpp rather than macros.hpp, since it feels more akin 
to ALWAYSINLINE/ATTRIBUTE_ALIGNED/etc than INCLUDE_JVMTI/X86_ONLY/etc.

cheers,
Per

> 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.
>