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

需积分: 10 109 浏览量更新于2024-07-16 收藏 641KB PDF 举报

"《Google C++ Style Guide》是Google公司制定的一份详细的C++编程规范，旨在提高代码的可读性和可维护性。这份PDF文档包含了C++编程的各种最佳实践和规则，涵盖了从命名约定、文件组织到类设计等多个方面。" 在C++编程中，遵循一定的规范和风格是至关重要的，因为这直接影响到代码的质量和团队间的协作效率。以下是一些《Google C++ Style Guide》中的关键知识点： 1. **Header Files**：推荐每个源文件只有一个声明，并且保持头文件自包含，避免包含循环依赖。同时，提倡使用`#ifndef`、`#define`、`#endif`来防止头文件被多次包含。 2. **Forward Declarations**：尽可能使用前向声明，减少头文件的依赖，提高编译速度。 3. **Inline Functions**：对于小函数，应考虑声明为内联函数以减少函数调用开销。 4. **Names and Order of Includes**：按照标准库、项目库、本地文件的顺序组织`#include`语句，并使用`<angle brackets>`包含系统库，使用`"double quotes"`包含本地文件。 5. **Scoping**：使用作用域来限制变量的作用范围，减少全局变量的使用，提高代码的安全性。 6. **Namespaces**：使用命名空间来避免名字冲突，特别是使用`using namespace`时需谨慎，以防止全局污染。 7. **Thread_local Variables**：对于线程局部变量，使用`thread_local`关键字，确保每个线程有自己的副本。 8. **Classes**：在构造函数中避免执行复杂操作，以确保构造过程的简洁。区分结构体（struct）和类（class），结构体默认为public，类默认为private。 9. **Copyable and Movable Types**：理解和正确实现拷贝构造函数和赋值运算符，以及移动构造函数和移动赋值运算符。 10. **Operator Overloading**：谨慎重载运算符，确保其行为符合预期，遵循一致的返回类型和参数列表。 11. **Access Control**：合理使用private、protected和public控制成员访问权限，保护数据安全。 12. **Function Overloading**：通过函数名和参数列表的不同来实现多态，但要避免过度使用。 13. **Default Arguments**：为函数提供默认参数，增加函数的灵活性，但也要注意避免副作用。 14. **Trailing Return Type Syntax**：C++11引入的尾置返回类型，可以提高代码可读性，特别是在模板函数中。 15. **Ownership and Smart Pointers**：使用智能指针（如`std::unique_ptr`、`std::shared_ptr`）管理内存，避免内存泄漏。 16. **cpplint**：Google提供的C++代码风格检查工具，可以帮助开发者遵守风格指南。 17. **Rvalue References**：C++11引入，用于支持右值引用和移动语义，优化对象的构造和赋值。 18. **Exceptions**：明智地使用异常处理，避免滥用`try-catch`块，确保异常安全。 19. **noexcept**：指定函数是否抛出异常，有助于优化和错误处理。 20. **Run-Time Type Information (RTTI)**：在必要时使用RTTI进行类型检查，但要谨慎，因为它可能影响性能。 21. **Casting**：推荐使用C++的静态_cast、dynamic_cast、reinterpret_cast和const_cast进行类型转换。 22. **Streams**：使用iostream库进行输入输出操作，如`std::cout`和`std::cin`。 23. **Use of const**：广泛使用const关键字来标记不可修改的对象，增强代码的稳定性和可读性。 24. **Use of constexpr**：在C++11中，使用constexpr声明常量表达式，使编译器在编译时计算值。 25. **Integer Types**：了解并正确使用不同整数类型，如`int`, `long`, `long long`, `unsigned`等，尤其在64位系统中要考虑兼容性问题。 26. **Preprocessor Macros**：尽量避免使用预处理器宏，除非确实必要，因为它们可能导致意外的副作用。 27. **0 and nullptr/NULL**：使用`nullptr`代替`0`或`NULL`来表示空指针，以消除二义性。 28. **sizeof**：使用`sizeof`操作符获取类型或表达式的大小，以进行内存计算。 29. **Type Deduction**：C++11引入的类型推断机制，如auto关键字，简化代码。 30. **Class Template Argument Deduction**：C++17引入的类模板参数推断，简化模板类的实例化。 31. **Lambda Expressions**：C++11引入的lambda表达式，使得编写匿名函数更为便捷。 32. **Template Metaprogramming**：利用模板元编程进行编译时计算，提高程序效率。以上只是《Google C++ Style Guide》中部分关键知识点的概述，实际文档中还有更多关于命名约定、注释规范、异常策略等细节内容，都值得程序员深入学习和遵循。

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:

Constant initialization is always allowed. Constant initialization of static storage

duration variables should be marked with constexpr or where possible the

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

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.

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...);).

// 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

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:

Foo& MyThreadLocalFoo() {

thread_local Foo result = ComplicatedInitialization();

return result;

}

thread_local Variables

thread_local variables at class or namespace scope must be initialized with a

true compile-time constant (i.e. they must have no dynamic initialization). To

enforce this, thread_local variables at class or namespace scope must be

annotated with ABSL_CONST_INIT (or constexpr, but that should be rare):

ABSL_CONST_INIT thread_local Foo foo = ...;

thread_local should be preferred over other mechanisms for defining thread-

local data.

Classes are the fundamental unit of code in C++. Naturally, we use them

extensively. This section lists the main dos and don'ts you should follow when

writing a class.

Avoid virtual method calls in constructors, and avoid initialization that can fail if

you can't signal an error.

Definition:

It is possible to perform arbitrary initialization in the body of the constructor.

Pros:

No need to worry about whether the class has been initialized or not.

Objects that are fully initialized by constructor call can be const and may

also be easier to use with standard containers or algorithms.

Cons:

If the work calls virtual functions, these calls will not get dispatched to the

subclass implementations. Future modification to your class can quietly

introduce this problem even if your class is not currently subclassed,

causing much confusion.

There is no easy way for constructors to signal errors, short of crashing the

program (not always appropriate) or using exceptions (which are

forbidden).

If the work fails, we now have an object whose initialization code failed, so

it may be an unusual state requiring a bool IsValid() state checking

mechanism (or similar) which is easy to forget to call.

You cannot take the address of a constructor, so whatever work is done in

the constructor cannot easily be handed off to, for example, another

thread.

Decision:

Constructors should never call virtual functions. If appropriate for your code ,

terminating the program may be an appropriate error handling response.

Otherwise, consider a factory function or Init() method as described in TotW

#42 . Avoid Init() methods on objects with no other states that affect which

Classes

Doing Work in Constructors

剩余84页未读，继续阅读

hktkzgd

粉丝: 0
资源: 4

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

C++ Style Guide.pdf

Google C++ Style Guide (中文版).pdf

Google C++ Style Guide中文PDF

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

谷歌C++规范 Google C++ Style Guide PDF

最新资源