Google C++编程规范PDF版

需积分: 20 6 浏览量更新于2024-07-16 收藏 839KB PDF 举报

"Google C++ Style Guide 是一份由Google公司制定并公开的C++编程风格规范文档，旨在提高代码质量和可读性。这份PDF版本包含了原HTML文档的所有内容，包括扉页和目录链接，方便读者查阅。文档详细规定了C++编程中的各种最佳实践和规则，覆盖了从头文件管理、命名约定、作用域、类设计到函数实现等多个方面。\n\n在C++编程中，头文件的管理是非常重要的。Google风格指南提倡自我包含的头文件，每个头文件应能独立工作，避免包含不必要的内容。它强调了#define Guard的使用，防止头文件被多次包含。此外，提倡使用前向声明减少编译依赖，同时合理使用内联函数来优化性能。\n\n关于命名和作用域，Google建议使用清晰的命名规则，如使用命名空间来组织代码，避免全局变量，尽量使用匿名命名空间和静态变量。对于非成员函数、静态成员函数和全局函数，应当谨慎使用，确保它们的作用范围和行为明确。\n\n在类的设计上，Google风格指南讨论了构造函数的工作、隐式类型转换、可复制和可移动类型的处理。推荐使用结构体代替类（structs vs. classes）时，除非需要访问控制。继承、运算符重载和访问控制的使用有明确的指导，以保持一致性。\n\n函数部分，Google提倡编写简洁的函数，避免过多的参数和返回值，鼓励使用引用而非指针作为参数。函数重载、默认参数和尾置返回类型都是被讨论的话题。Google特定的部分，如所有权和智能指针的使用，以及cpplint工具的介绍，提供了Google内部代码审查的标准。\n\n文档还涵盖了C++的一些高级特性，如右值引用、友元、异常处理、noexcept关键字、运行时类型信息（RTTI）、类型转换、流操作、const的使用、constexpr以及整型类型的使用。特别提到了64位平台的兼容性问题，预处理器宏的管理，以及 nullptr 和 NULL 的区别。\n\n更现代的C++特性，如类型推导（type deduction）、类模板参数推导（class template argument deduction）和lambda表达式的使用，也有详尽的解释。模板元编程（template metaprogramming）作为C++的一个强大工具，也被纳入了讨论范围。\n\n总而言之，Google C++ Style Guide 是一份全面的编程规范，对于任何想要遵循一致、清晰且易于维护的C++编码风格的开发者来说，都是一份宝贵的参考资源。遵循这些规则，可以提升团队协作效率，降低代码维护难度，提高软件质量。"

storage duration if they are trivially destructible. Fundamental types (like

pointers and int) are trivially destructible, as are arrays of trivially destructible

types. Note that variables marked with constexpr are trivially destructible.

// bad: non-trivial destructor

const std::string kFoo = "foo";

// bad for the same reason, even though kBar is a reference (the

// rule also applies to lifetime-extended temporary objects)

const std::string& kBar = StrCat("a", "b", "c");

void bar() {

// bad: non-trivial destructor

static std::map<int, int> kData = {{1, 0}, {2, 0}, {3, 0}};

}

Note that references are not objects, and thus they are not subject to the

constraints on destructibility. The constraint on dynamic initialization still

applies, though. In particular, a function-local static reference of the form

static T& t = *new T; is allowed.

Decision on initialization

Initialization is a more complex topic. This is because we must not only consider

whether class constructors execute, but we must also consider the evaluation of

the initializer:

int n = 5; // fine

int m = f(); // ? (depends on f)

Foo x; // ? (depends on Foo::Foo)

Bar y = g(); // ? (depends on g and on Bar::Bar)

All but the first statement expose us to indeterminate initialization ordering.

The concept we are looking for is called

constant initialization

in the formal

language of the C++ standard. It means that the initializing expression is a

constant expression, and if the object is initialized by a constructor call, then the

constructor must be specified as constexpr, too:

const int kNum = 10; // allowed

struct X { int n; };

const X kX[] = {{1}, {2}, {3}}; // allowed

void foo() {

static const char* const kMessages[] = {"hello", "world"}; // allowed

}

// allowed: constexpr guarantees trivial destructor

constexpr std::array<int, 3> kArray = {{1, 2, 3}};

struct Foo { constexpr Foo(int) {} };

int n = 5; // fine, 5 is a constant expression

Foo x(2); // fine, 2 is a constant expression and the chosen constructo

Foo a[] = { Foo(1), Foo(2), Foo(3) }; // fine

Constant initialization is always allowed. Constant initialization of static storage

duration variables should be marked with constexpr or where possible the

ABSL_CONST_INIT attribute. Any non-local static storage duration variable that is

not so marked should be presumed to have dynamic initialization, and reviewed

very carefully.

By contrast, the following initializations are problematic:

Dynamic initialization of nonlocal variables is discouraged, and in general it is

forbidden. However, we do permit it if no aspect of the program depends on the

sequencing of this initialization with respect to all other initializations. Under

those restrictions, the ordering of the initialization does not make an observable

difference. For example:

int p = getpid(); // allowed, as long as no other static variable

// uses p in its own initialization

Dynamic initialization of static local variables is allowed (and common).

Common patterns

Global strings: if you require a global or static string constant, consider

using a simple character array, or a char pointer to the first element of a

string literal. String literals have static storage duration already and are

usually sufficient.

Maps, sets, and other dynamic containers: if you require a static, fixed

collection, such as a set to search against or a lookup table, you cannot

use the dynamic containers from the standard library as a static variable,

since they have non-trivial destructors. Instead, consider a simple array of

trivial types, e.g. an array of arrays of ints (for a "map from int to int"), or

an array of pairs (e.g. pairs of int and const char*). For small collections,

linear search is entirely sufficient (and efficient, due to memory locality);

consider using the facilities from absl/algorithm/container.h for the

standard operations. If necessary, keep the collection in sorted order and

use a binary search algorithm. If you do really prefer a dynamic container

from the standard library, consider using a function-local static pointer, as

described below.

Smart pointers (unique_ptr, shared_ptr): smart pointers execute cleanup

during destruction and are therefore forbidden. Consider whether your

use case fits into one of the other patterns described in this section. One

simple solution is to use a plain pointer to a dynamically allocated object

and never delete it (see last item).

Static variables of custom types: if you require static, constant data of a

type that you need to define yourself, give the type a trivial destructor and

a constexpr constructor.

// Some declarations used below.

time_t time(time_t*); // not constexpr!

int f(); // not constexpr!

struct Bar { Bar() {} };

// Problematic initializations.

time_t m = time(nullptr); // initializing expression not a constant expr

Foo y(f()); // ditto

Bar b; // chosen constructor Bar::Bar() not constexpr

If all else fails, you can create an object dynamically and never delete it by

using a function-local static pointer or reference (e.g.

static const auto& impl = *new T(args...);).

thread_local variables that aren't declared inside a function must be initialized

with a true compile-time constant, and this must be enforced by using the

ABSL_CONST_INIT attribute. Prefer thread_local over other ways of defining

thread-local data.

Definition:

Starting with C++11, variables can be declared with the thread_local specifier:

thread_local Foo foo = ...;

Such a variable is actually a collection of objects, so that when different threads

access it, they are actually accessing different objects. thread_local variables are

much like static storage duration variables in many respects. For instance, they

can be declared at namespace scope, inside functions, or as static class

members, but not as ordinary class members.

thread_local variable instances are initialized much like static variables, except

that they must be initialized separately for each thread, rather than once at

program startup. This means that thread_local variables declared within a

function are safe, but other thread_local variables are subject to the same

initialization-order issues as static variables (and more besides).

thread_local variable instances are destroyed when their thread terminates, so

they do not have the destruction-order issues of static variables.

Pros:

Thread-local data is inherently safe from races (because only one thread

can ordinarily access it), which makes thread_local useful for concurrent

programming.

thread_local is the only standard-supported way of creating thread-local

data.

Cons:

Accessing a thread_local variable may trigger execution of an

unpredictable and uncontrollable amount of other code.

thread_local variables are effectively global variables, and have all the

drawbacks of global variables other than lack of thread-safety.

The memory consumed by a thread_local variable scales with the number

of running threads (in the worst case), which can be quite large in a

program.

An ordinary class member cannot be thread_local.

thread_local may not be as efficient as certain compiler intrinsics.

Decision:

thread_local variables inside a function have no safety concerns, so they can be

used without restriction. Note that you can use a function-scope thread_local to

simulate a class- or namespace-scope thread_local by defining a function or

static method that exposes it:

thread_local Variables

剩余84页未读，继续阅读

LarryZjh

粉丝: 27
资源: 3

Google C++编程规范PDF版

Google C++ Style Guide: 英文版，带目录与标签

谷歌C++编程风格指南PDF版

谷歌C++编码规范中文版：提升软件质量的通用指南

Google C++ Style Guide.zip

Google C++ Style Guide中文.pdf

Google C++ Style Guide 20160305.pdf

Google C++ Style Guide译文.pdf

google-styleguide.pdf

Google C++ Style Guide_英文版.pdf

Google C++ Style Guide中文PDF

最新资源