On Wed, 8 Oct 2025 18:12:44 GMT, John R Rose <[email protected]> wrote:
>> Please review this change to the HotSpot Style Guide to suggest that C++ >> Standard Library components may be used, after appropriate vetting and >> discussion, rather than just a blanket "no, don't use it" with a few very >> narrow exceptions. It provides some guidance on that vetting process and >> the criteria to use, along with usage patterns. >> >> In particular, it proposes that Standard Library headers should not be >> included directly, but instead through HotSpot-provided wrapper headers. This >> gives us a place to document usage, provide workarounds for platform issues >> in >> a single place, and so on. >> >> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and >> `<type_traits>`, along with updates to use them. I have a separate change for >> `<new>` that I plan to propose later, under JDK-8369187. There will be >> additional followups for other C compatibility headers besides `<cstddef>`. >> >> This PR also cleans up some nomenclature issues around forbid vs exclude and >> the like. >> >> Testing: mach5 tier1-5, GHA sanity tests > > doc/hotspot-style.md line 629: > >> 627: occur. The C++98/03 `std::allocator` class is too limited to support our >> 628: usage. But changes to the allocator concept in more recent Standards >> removed >> 629: some of the limitations, supporting statefull allocators. HotSpot may, >> in the > > s/statefull/stateful/ Fixed locally for next push. > doc/hotspot-style.md line 647: > >> 645: using those names easier, since the qualifiers don't need to be >> included. But >> 646: there are reasons not to do that. >> 647: > > s/reasons/several reasons/ (to better tee up the following bullet list) Fixed locally for next push. > doc/hotspot-style.md line 651: > >> 649: headers may be included, adding to the list of names being used. >> Also, >> 650: future versions of the Standard Library may add currently unknown >> names to >> 651: the headers already being included. > > Maybe mention the `assert` macro at the end of the bullet, if there is no > other example of a previous name collision: > >> …already being included. (We already have a conflict from the HotSpot >> `assert` macro, although in that case the `std::` prefix is not applicable.) There aren't any previous examples because we don't have any examples of doing this thing that we're warning against (`using` a namespace). `assert` is a different problem, unrelated to namespaces. (Remember that one of the usual knocks against macros is that they don't respect namespaces.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2415313253 PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2415313425 PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2415313670
