RFC: 8247976: Update HotSpot Style Guide for C++14 adoption

[Kim Barrett]

> On Jul 27, 2020, at 1:29 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> On 7/25/20 1:50 PM, Kim Barrett wrote:
>>> On Jul 24, 2020, at 7:49 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>> 
>>> Thank you, Kim for very nice work.
>>> 
>>> I agree to have it in jdk/jdk/doc which we can always reference and people can see. And also track all changes.
>> Thanks.
>>> *Structure and Formatting*
>>> 
>>> I think ordering of sectin should by importance: naming rules and commenting are more important then spacing:
>> Your suggested ordering seems better; done.
>>> May be next should be split into sub-paragraphs instead of one long paragraph:
>>> 
>>> . Use bool for boolean values. […]
>> I've reworded this and broken it up into a main bullet and sub-bullets.
>>> *Use of C++ Features*
>>> 
>>> I think enum, thread_local, nullptr, <atomic> could be subsection of some new section which explicitly unite them.
>>> At first I mistakenly saw them as subsections of *C++ Standard Library* section.
>> I can see how that confusion could arise.  I don't think those
>> features need a new subsection (I'm not sure what I would call such
>> anyway), as they really only differ from many of the others at the
>> same level by using C++ identifiers or other syntax in the heading,
>> and perhaps being a bit smaller in size.  What I've done is reorder
>> things so there are other, more obviously not Standard Library,
>> subsections immediately following the Standard Library subsection.
> 
> Yes, the reordering is fine too.
> 
>>> You did not say anything about preferable way of fields initialization in constructors to verify initialization order during compilation. We did refactoring before but new code may not follow it.
>> Preferring constructors use ctor-initializers would be a new guideline
>> that would be good to have. But the work we did a while ago to ensure
>> ctor-initializers are, and remain in, the proper order is enforced by
>> having also enabled -Wreorder. I've added to my list a TODO item to
>> follow up in this area.
>>> What about C++ pragmas?
>> Guidance on pragma and attribute usage would be another new guideline
>> that would be good to have. I've added to my list a TODO item to
>> follow up in this area.
>>> Example of "new code should use integral constants"?
>>> 
>>> I wish to see more embedded examples in this document but they can be added later.
>> I’m leaving additional examples for future work.
> 
> Good. Yes, I agree that above things can be done after this initial work.
> 
> Thanks,
> Vladimir

Thanks.