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

[Kim Barrett]

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

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