RFR: 8234779: Provide idiom for declaring classes noncopyable

[coleen.phillimore at oracle.com]

Hi, I saw this thread while on vacation and thought I would hate it, but 
I really don't.  I for one, would greatly appreciate not having to get 
all the syntax quite right when declaring a class not copyable (or ask 
Kim!).

I did expect the macro to be in globalDefinitions.hpp as well though.

Thanks,
Coleen

On 12/2/19 4:04 AM, Per Liden wrote:
> 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.
>>