#includes only work properly when your code is
-consistent with the expectations of the tooling. In many cases, rules
-that are attributed to "Be Consistent" boil down to "Just pick one and
-stop worrying about it"; the potential value of allowing flexibility
-on these points is outweighed by the cost of having people argue over
-them. #includes only
+work properly when your code is consistent with the expectations of
+the tooling. In many cases, rules that are attributed to "Be
+Consistent" boil down to "Just pick one and stop worrying about it";
+the potential value of allowing flexibility on these points is
+outweighed by the cost of having people argue over them. However,
+there are limits to consistency; it is a good tie breaker when there
+is no clear technical argument, nor a long-term direction. It applies
+more heavily locally (per file, or for a tightly-related set of
+interfaces). Consistency should not generally be used as a
+justification to do things in an old style without considering the
+benefits of the new style, or the tendency of the codebase to converge
+on newer styles over time.
protected when using
Google
-Test).
+Test.
If a test fixture class is defined outside of the .cc file it is used in, for example in a .h file,
make data members private.
@@ -1695,7 +1701,7 @@ sections that would be empty.
Within each section, prefer grouping similar
kinds of declarations together, and prefer the
following order: types (including typedef,
-using, and nested structs and classes),
+using, enum, and nested structs and classes),
constants, factory functions, constructors and assignment
operators, destructor, all other methods, data members.
const pointer when the non-optional form would
have used a reference. Use non-const pointers to represent
optional outputs and optional input/output parameters.
+
+
Avoid defining functions that require a const reference parameter
to outlive the call, because const reference parameters bind
@@ -2505,7 +2513,7 @@ workarounds disguise your true intent.
Use C++-style casts
like static_cast<float>(double_value), or brace
initialization for conversion of arithmetic types like
-int64 y = int64{1} << 42. Do not use
+int64_t y = int64_t{1} << 42. Do not use
cast formats like (int)x unless the cast is to
void. You may use cast formats like `T(x)` only when
`T` is a class type.
int64{x}). This is the safest approach because code
+ (e.g., int64_t{x}). This is the safest approach because code
will not compile if conversion can result in information loss. The
syntax is also concise.absl::bit_cast to interpret the raw bits of a
value using a different type of the same size (a type pun), such as
interpreting the bits of a double as
- int64.int64_t.
int64_t/uint64_t
+ disk. Any class/structure with a int64_t/uint64_t
member will by default end up being 8-byte aligned on a
64-bit system. If you have such structures being shared
on disk between 32-bit and 64-bit code, you will need
@@ -2998,13 +2987,9 @@ problems of printing, comparisons, and structure alignment.
Use braced-initialization as needed to create 64-bit constants. For example:
- - -int64_t my_value{0x123456789};
uint64_t my_mask{3ULL << 48};
-Template metaprogramming allows extremely flexible interfaces that
are type safe and high performance. Facilities like
-Google Test,
+GoogleTest,
std::tuple, std::function, and
Boost.Spirit would be impossible without it.
// If we have enough memory, mmap the data portion too. -mmap_budget = max<int64>(0, mmap_budget - index_->length()); +mmap_budget = max<int64_t>(0, mmap_budget - index_->length()); if (mmap_budget >= data_size_ && !MmapData(mmap_chunk_bytes, mlock)) return; // Error already logged.