From 8c4da230fc15e01e0ba3545c8a6ff55bc3da4649 Mon Sep 17 00:00:00 2001 From: Daniel Cheng Date: Thu, 5 Sep 2024 13:32:14 -0700 Subject: [PATCH] Update C++ style guide (#835) - Explicitly ban `long double` - Use absl formatting libraries or `std::ostream` over printf-style functions. - Portability: use serialization libraries instead of copying the in-memory representation. - Update guidance to use `uintptr_t` (previously `intptr_t`) when working with pointers as integers. - Ban C++20 modules. - Ban coroutines (though this is expected to be temporary). - Minor wording updates. --- cppguide.html | 131 +++++++++++++++++++++++++++----------------------- 1 file changed, 72 insertions(+), 59 deletions(-) diff --git a/cppguide.html b/cppguide.html index 7c87799..dca5dfe 100644 --- a/cppguide.html +++ b/cppguide.html @@ -3026,70 +3026,53 @@ not to mix signedness, and try to avoid unsigned types (except for representing bitfields or modular arithmetic). Do not use an unsigned type merely to assert that a variable is non-negative.

-

64-bit Portability

+

Floating-Point Types

-

Code should be 64-bit and 32-bit friendly. Bear in mind -problems of printing, comparisons, and structure alignment.

+

Of the built-in C++ floating-point types, the only ones used + are float and +double. You may assume that these types represent IEEE-754 binary32 +and binary64, respectively.

+ +

Do not use long double, as it gives non-portable +results.

+ + +

Architecture Portability

+ +

Write architecture-portable code. Do not rely on CPU features specific to a +single processor.

Preprocessor Macros

@@ -3893,6 +3876,37 @@ Requirements that are unenforced at compile time should instead be imposed via other mechanisms such as comments, assertions, or tests.

+

C++20 modules

+ +

Do not use C++20 Modules.

+ +

C++20 introduces "modules", a new language feature designed as an +alternative to textual inclusion of header files. It introduces three +new keywords to support +this: module, export, +and import. + +

Modules are a big shift in how C++ is written and compiled, and we +are still assessing how they may fit into Google's C++ ecosystem in +the future. Furthermore, they are not currently well-supported by our +build-systems, compilers, and other tooling, and need further +exploration as to the best-practices when writing and using them.

+ + + +

Coroutines

+ +

Do not use coroutines (yet).

+ +

Do not include the <coroutine> header, +or use the co_await, co_yield, +or co_return keywords.

+ +

NOTE: this ban is expected to be temporary, while further +guidance is being developed. + +

+

Boost

Use only approved libraries from the Boost library @@ -3997,11 +4011,11 @@ the future.

-

Other C++ Features

+

Disallowed standard library features

As with Boost, some modern C++ -extensions encourage coding practices that hamper +library functionality encourages coding practices that hamper readability—for example by removing checked redundancy (such as type names) that may be helpful to readers, or by encouraging template @@ -4010,8 +4024,7 @@ available through existing mechanisms, which may lead to confusion and conversion costs.

-

In addition to what's described in the rest of the style -guide, the following C++ features may not be used:

+

The following C++ standard library features may not be used:

-

C++ files should end in .cc and header files should end in -.h. Files that rely on being textually included at specific points +

C++ files should have a .cc filename extension, and header files +should have a .h extension. Files that rely on being textually included at specific points should end in .inc (see also the section on self-contained headers).

@@ -5917,7 +5930,7 @@ which we discuss here.

-

Existing Non-conformant Code

+

Existing Non-conformant Code

You may diverge from the rules when dealing with code that does not conform to this style guide.