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

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Jul 27 17:29:14 UTC 2020


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



More information about the hotspot-dev mailing list