P4
The Hotspot Style Guide
https://wiki.openjdk.java.net/display/HotSpot/StyleGuide
should be updated to no longer require the use of enum for defining constants in class definitions. Specifically, item 7 of the Top Ten List presently says:
7. #NamedCons Assign names to constant literals and use the names
instead. Use enum to name integer constants inside class
definitions.
It should be changed to have the second sentence removed in its entirety, leaving:
7. #NamedCons Assign names to constant literals and use the names instead.
The rationale for this change is that requiring the use of enums for constants in class definitions prevents fine control of the types of such constants. The only possible types for enumerators are int or unsigned int, chosen by the compiler based on the range of values. As a consequence of this, we often have constants whose types don't match their semantics and usage, with casts often used to cope with that.
The idiomatic use of enums for defining such constants is derived from some compilers not dealing so well with static const integral-typed in-class member initialization. According to Boost's config macros (see BOOST_NO_INCLASS_MEMBER_INITIALIZATION and BOOST_STATIC_CONSTANT) this includes at least
MPW 8.90 and earlier
IBM Visual Age with __IBMCPP__ <= 502
SunPro before 5.7
For example, the comment for SunPro 5.2 and earlier is
// although sunpro 5.2 supports the syntax for
// inline initialization it often gets the value
// wrong, especially where the value is computed
// from other constants (J Maddock 6th May 2001)
We don't care about any of those anymore. As evidence for that, Hotspot code already contains a few (roughly 100) constants directly defined in class definitions, rather than using enum as the Style Guide suggests. Some of these are of type int, but most are not (bool and size_t seem to be common among those).
Also note that using enum to define constants that are semantically boolean is contrary to item 8 of the Style Guide Top Ten List.
https://wiki.openjdk.java.net/display/HotSpot/StyleGuide
should be updated to no longer require the use of enum for defining constants in class definitions. Specifically, item 7 of the Top Ten List presently says:
7. #NamedCons Assign names to constant literals and use the names
instead. Use enum to name integer constants inside class
definitions.
It should be changed to have the second sentence removed in its entirety, leaving:
7. #NamedCons Assign names to constant literals and use the names instead.
The rationale for this change is that requiring the use of enums for constants in class definitions prevents fine control of the types of such constants. The only possible types for enumerators are int or unsigned int, chosen by the compiler based on the range of values. As a consequence of this, we often have constants whose types don't match their semantics and usage, with casts often used to cope with that.
The idiomatic use of enums for defining such constants is derived from some compilers not dealing so well with static const integral-typed in-class member initialization. According to Boost's config macros (see BOOST_NO_INCLASS_MEMBER_INITIALIZATION and BOOST_STATIC_CONSTANT) this includes at least
MPW 8.90 and earlier
IBM Visual Age with __IBMCPP__ <= 502
SunPro before 5.7
For example, the comment for SunPro 5.2 and earlier is
// although sunpro 5.2 supports the syntax for
// inline initialization it often gets the value
// wrong, especially where the value is computed
// from other constants (J Maddock 6th May 2001)
We don't care about any of those anymore. As evidence for that, Hotspot code already contains a few (roughly 100) constants directly defined in class definitions, rather than using enum as the Style Guide suggests. Some of these are of type int, but most are not (bool and size_t seem to be common among those).
Also note that using enum to define constants that are semantically boolean is contrary to item 8 of the Style Guide Top Ten List.
- relates to
-
JDK-8152856 Xcode 7.3 -Wshift-negative-value compile failure on Mac OS X
-
- Resolved
-