华为C++编程规范

• 华为C++编程规范

C++语言编程规范

目的

规则并不是完美的，通过禁止在特定情况下有用的特性，可能会对代码实现造成影响。但是我们制定规则的目的“为了大多数程序员可以得到更多的好处”， 如果在团队运作中认为某个规则无法遵循，希望可以共同改进该规则。 参考该规范之前，希望您具有相应的C++语言基础能力，而不是通过该文档来学习C++语言。

1. 了解C++语言的ISO标准；
2. 熟知C++语言的基本语言特性，包括C++ 03/11/14/17相关特性；
3. 了解C++语言的标准库；

总体原则

代码需要在保证功能正确的前提下，满足可读、可维护、安全、可靠、可测试、高效、可移植的特征要求。

重点关注

1. 约定C++语言的编程风格，比如命名，排版等。
2. C++语言的模块化设计，如何设计头文件，类，接口和函数。
3. C++语言相关特性的优秀实践，比如常量，类型转换，资源管理，模板等。
4. 现代C++语言的优秀实践，包括C++11/14/17中可以提高代码可维护性，提高代码可靠性的相关约定。
5. 本规范优先适于用C++17版本。

约定

规则：编程时必须遵守的约定(must)

建议：编程时应该遵守的约定(should)

本规范适用通用C++标准, 如果没有特定的标准版本，适用所有的版本(C++03/11/14/17)。

例外

无论是’规则’还是’建议’，都必须理解该条目这么规定的原因，并努力遵守。 但是，有些规则和建议可能会有例外。

在不违背总体原则，经过充分考虑，有充足的理由的前提下，可以适当违背规范中约定。 例外破坏了代码的一致性，请尽量避免。‘规则’的例外应该是极少的。

下列情况，应风格一致性原则优先： 修改外部开源代码、第三方代码时，应该遵守开源代码、第三方代码已有规范，保持风格统一。

2 命名

通用命名

驼峰风格(CamelCase) 大小写字母混用，单词连在一起，不同单词间通过单词首字母大写来分开。 按连接后的首字母是否大写，又分: 大驼峰(UpperCamelCase)和小驼峰(lowerCamelCase)

注意： 上表中__常量__是指全局作用域、namespace域、类的静态成员域下，以 const或constexpr 修饰的基本数据类型、枚举、字符串类型的变量，不包括数组和其他类型变量。 上表中__变量__是指除常量定义以外的其他变量，均使用小驼峰风格。

文件命名

规则2.2.1 C++文件以.cpp结尾，头文件以.h结尾

我们推荐使用.h作为头文件的后缀，这样头文件可以直接兼容C和C++。 我们推荐使用.cpp作为实现文件的后缀，这样可以直接区分C++代码，而不是C代码。

目前业界还有一些其他的后缀的表示方法：

• 头文件： .hh, .hpp, .hxx
• cpp文件：.cc, .cxx, .c

如果当前项目组使用了某种特定的后缀，那么可以继续使用，但是请保持风格统一。 但是对于本文档，我们默认使用.h和.cpp作为后缀。

规则2.2.2 C++文件名和类名保持一致

C++的头文件和cpp文件名和类名保持一致，使用下划线小写风格。

如果有一个类叫DatabaseConnection，那么对应的文件名：

• database_connection.h
• database_connection.cpp

结构体，命名空间，枚举等定义的文件名类似。

函数命名

函数命名统一使用大驼峰风格，一般采用动词或者动宾结构。

class List {
public:
	void AddElement(const Element& element);
	Element GetElement(const unsigned int index) const;
	bool IsEmpty() const;
};

namespace Utils {
    void DeleteUser();
}

类型命名

类型命名采用大驼峰命名风格。 所有类型命名——类、结构体、联合体、类型定义（typedef）、枚举——使用相同约定，例如：

// classes, structs and unions
class UrlTable { ...
class UrlTableTester { ...
struct UrlTableProperties { ...
union Packet { ...

// typedefs
typedef std::map<std::string, UrlTableProperties*> PropertiesMap;

// enums
enum UrlTableErrors { ...

对于命名空间的命名，建议使用大驼峰：

// namespace
namespace OsUtils {
 
namespace FileUtils {
     
}
 
}

建议2.4.1 避免滥用 typedef或者#define 对基本类型起别名

除有明确的必要性，否则不要用 typedef/#define 对基本数据类型进行重定义。 优先使用<cstdint>头文件中的基本类型：

变量命名

通用变量命名采用小驼峰，包括全局变量，函数形参，局部变量，成员变量。

std::string tableName;  // Good: 推荐此风格
std::string tablename;  // Bad: 禁止此风格
std::string path;       // Good: 只有一个单词时，小驼峰为全小写

规则2.5.1 全局变量应增加 ‘g_’ 前缀，静态变量命名不需要加特殊前缀

全局变量是应当尽量少使用的，使用时应特别注意，所以加上前缀用于视觉上的突出，促使开发人员对这些变量的使用更加小心。

• 全局静态变量命名与全局变量相同。
• 函数内的静态变量命名与普通局部变量相同。
• 类的静态成员变量和普通成员变量相同。

int g_activeConnectCount;

void Func()
{
    static int packetCount = 0; 
    ...
}

规则2.5.2 类的成员变量命名以小驼峰加后下划线组成

class Foo {
private:
    std::string fileName_;   // 添加_后缀，类似于K&R命名风格
};

对于struct/union的成员变量，仍采用小驼峰不加后缀的命名方式，与局部变量命名风格一致。

宏、常量、枚举命名

宏、枚举值采用全大写，下划线连接的格式。 全局作用域内，有名和匿名namespace内的 const 常量，类的静态成员常量，全大写，下划线连接；函数局部 const 常量和类的普通const成员变量，使用小驼峰命名风格。

#define MAX(a, b)   (((a) < (b)) ? (b) : (a)) // 仅对宏命名举例，并不推荐用宏实现此类功能

enum TintColor {    // 注意，枚举类型名用大驼峰，其下面的取值是全大写，下划线相连
    RED,
    DARK_RED,
    GREEN,
    LIGHT_GREEN
};

int Func(...)
{
    const unsigned int bufferSize = 100;    // 函数局部常量
    char *p = new char[bufferSize];
    ...
}

namespace Utils {
	const unsigned int DEFAULT_FILE_SIZE_KB = 200;        // 全局常量
}

3 格式

行宽

规则3.1.1 行宽不超过 120 个字符

建议每行字符数不要超过 120 个。如果超过120个字符，请选择合理的方式进行换行。

例外:

• 如果一行注释包含了超过120 个字符的命令或URL，则可以保持一行，以方便复制、粘贴和通过grep查找；
• 包含长路径的 #include 语句可以超出120 个字符，但是也需要尽量避免；
• 编译预处理中的error信息可以超出一行。 预处理的 error 信息在一行便于阅读和理解，即使超过 120 个字符。

#ifndef XXX_YYY_ZZZ
#error Header aaaa/bbbb/cccc/abc.h must only be included after xxxx/yyyy/zzzz/xyz.h, because xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
#endif

缩进

规则3.2.1 使用空格进行缩进，每次缩进4个空格

只允许使用空格(space)进行缩进，每次缩进为 4 个空格。不允许使用Tab符进行缩进。 当前几乎所有的集成开发环境（IDE）都支持配置将Tab符自动扩展为4空格输入；请配置你的IDE支持使用空格进行缩进。

大括号

规则3.3.1 使用 K&R 缩进风格

K&R风格 换行时，函数（不包括lambda表达式）左大括号另起一行放行首，并独占一行；其他左大括号跟随语句放行末。 右大括号独占一行，除非后面跟着同一语句的剩余部分，如 do 语句中的 while，或者 if 语句的 else/else if，或者逗号、分号。

如：

struct MyType {     // 跟随语句放行末，前置1空格
    ...
};

int Foo(int a)
{                   // 函数左大括号独占一行，放行首
    if (...) {
        ...
    } else {
        ...
    }
}

推荐这种风格的理由：

• 代码更紧凑；
• 相比另起一行，放行末使代码阅读节奏感上更连续；
• 符合后来语言的习惯，符合业界主流习惯；
• 现代集成开发环境（IDE）都具有代码缩进对齐显示的辅助功能，大括号放在行尾并不会对缩进和范围产生理解上的影响。

对于空函数体，可以将大括号放在同一行：

class MyClass {
public:
    MyClass() : value_(0) {}
   
private:
    int value_;
};

函数声明和定义

规则3.4.1 函数声明和定义的返回类型和函数名在同一行；函数参数列表超出行宽时要换行并合理对齐

在声明和定义函数的时候，函数的返回值类型应该和函数名在同一行；如果行宽度允许，函数参数也应该放在一行；否则，函数参数应该换行，并进行合理对齐。 参数列表的左圆括号总是和函数名在同一行，不要单独一行；右圆括号总是跟随最后一个参数。

换行举例：

ReturnType FunctionName(ArgType paramName1, ArgType paramName2)   // Good：全在同一行
{
    ...
}

ReturnType VeryVeryVeryLongFunctionName(ArgType paramName1,     // 行宽不满足所有参数，进行换行
                                        ArgType paramName2,     // Good：和上一行参数对齐
                                        ArgType paramName3)
{
    ...
}

ReturnType LongFunctionName(ArgType paramName1, ArgType paramName2, // 行宽限制，进行换行
    ArgType paramName3, ArgType paramName4, ArgType paramName5)     // Good: 换行后 4 空格缩进
{
    ...
}

ReturnType ReallyReallyReallyReallyLongFunctionName(            // 行宽不满足第1个参数，直接换行
    ArgType paramName1, ArgType paramName2, ArgType paramName3) // Good: 换行后 4 空格缩进
{
    ...
}

函数调用

规则3.5.1 函数调用入参列表应放在一行，超出行宽换行时，保持参数进行合理对齐

函数调用时，函数参数列表放在一行。参数列表如果超过行宽，需要换行并进行合理的参数对齐。 左圆括号总是跟函数名，右圆括号总是跟最后一个参数。

换行举例：

ReturnType result = FunctionName(paramName1, paramName2);   // Good：函数参数放在一行

ReturnType result = FunctionName(paramName1,
                                 paramName2,                // Good：保持与上方参数对齐
                                 paramName3);

ReturnType result = FunctionName(paramName1, paramName2,
    paramName3, paramName4, paramName5);                    // Good：参数换行，4 空格缩进

ReturnType result = VeryVeryVeryLongFunctionName(           // 行宽不满足第1个参数，直接换行
    paramName1, paramName2, paramName3);                    // 换行后，4 空格缩进

如果函数调用的参数存在内在关联性，按照可理解性优先于格式排版要求，对参数进行合理分组换行。

// Good：每行的参数代表一组相关性较强的数据结构，放在一行便于理解
int result = DealWithStructureLikeParams(left.x, left.y,     // 表示一组相关参数
                                         right.x, right.y);  // 表示另外一组相关参数

if语句

规则3.6.1 if语句必须要使用大括号

我们要求if语句都需要使用大括号，即便只有一条语句。

理由：

• 代码逻辑直观，易读；
• 在已有条件语句代码上增加新代码时不容易出错；
• 对于在if语句中使用函数式宏时，有大括号保护不易出错（如果宏定义时遗漏了大括号）。

if (objectIsNotExist) {         // Good：单行条件语句也加大括号
    return CreateNewObject();
}

规则3.6.2 禁止 if/else/else if 写在同一行

条件语句中，若有多个分支，应该写在不同行。

如下是正确的写法：

if (someConditions) {
    DoSomething();
    ...
} else {  // Good: else 与 if 在不同行
    ...
}

下面是不符合规范的案例：

if (someConditions) { ... } else { ... } // Bad: else 与 if 在同一行

循环语句

规则3.7.1 循环语句必须使用大括号

和条件表达式类似，我们要求for/while循环语句必须加上大括号，即便循环体是空的，或循环语句只有一条。

for (int i = 0; i < someRange; i++) {   // Good: 使用了大括号
    DoSomething();
}

while (condition) { }   // Good：循环体是空，使用大括号

while (condition) {
    continue;           // Good：continue 表示空逻辑，使用大括号
}

坏的例子：

for (int i = 0; i < someRange; i++)
    DoSomething();      // Bad: 应该加上括号

while (condition);      // Bad：使用分号容易让人误解是while语句中的一部分

switch语句

规则3.8.1 switch 语句的 case/default 要缩进一层

switch 语句的缩进风格如下：

switch (var) {
    case 0:             // Good: 缩进
        DoSomething1(); // Good: 缩进
        break;
    case 1: {           // Good: 带大括号格式
        DoSomething2();
        break;
    }
    default:
        break;
}

switch (var) {
case 0:                 // Bad: case 未缩进
    DoSomething();
    break;
default:                // Bad: default 未缩进
    break;
}

表达式

建议3.9.1 表达式换行要保持换行的一致性，运算符放行末

较长的表达式，不满足行宽要求的时候，需要在适当的地方换行。一般在较低优先级运算符或连接符后面截断，运算符或连接符放在行末。 运算符、连接符放在行末，表示“未结束，后续还有”。 例：

// 假设下面第一行已经不满足行宽要求

if ((currentValue > threshold) &&  // Good：换行后，逻辑操作符放在行尾
    someCondition) {
    DoSomething();
    ...
}

int result = reallyReallyLongVariableName1 +    // Good
             reallyReallyLongVariableName2;

表达式换行后，注意保持合理对齐，或者4空格缩进。参考下面例子

int sum = longVariableName1 + longVariableName2 + longVariableName3 +
    longVariableName4 + longVariableName5 + longVariableName6;         // Good: 4空格缩进

int sum = longVariableName1 + longVariableName2 + longVariableName3 +
          longVariableName4 + longVariableName5 + longVariableName6;   // Good: 保持对齐

变量赋值

规则3.10.1 多个变量定义和赋值语句不允许写在一行

每行只有一个变量初始化的语句，更容易阅读和理解。

int maxCount = 10;
bool isCompleted = false;

下面是不符合规范的示例：

int maxCount = 10; bool isCompleted = false; // Bad：多个变量初始化需要分开放在多行，每行一个变量初始化
int x, y = 0;  // Bad：多个变量定义需要分行，每行一个

int pointX;
int pointY;
...
pointX = 1; pointY = 2;  // Bad：多个变量赋值语句放同一行

例外：for 循环头、if 初始化语句（C++17）、结构化绑定语句（C++17）中可以声明和初始化多个变量。这些语句中的多个变量声明有较强关联，如果强行分成多行会带来作用域不一致，声明和初始化割裂等问题。

初始化

初始化包括结构体、联合体、及数组的初始化

规则3.11.1 初始化换行时要有缩进，并进行合理对齐

结构体或数组初始化时，如果换行应保持4空格缩进。 从可读性角度出发，选择换行点和对齐位置。

const int rank[] = {
    16, 16, 16, 16, 32, 32, 32, 32,
    64, 64, 64, 64, 32, 32, 32, 32
};

指针与引用

建议3.12.1 指针类型"*“跟随变量名或者类型，不要两边都留有或者都没有空格

指针命名: *靠左靠右都可以，但是不要两边都有或者都没有空格。

int* p = nullptr;  // Good
int *p = nullptr;  // Good

int*p = nullptr;   // Bad
int * p = nullptr; // Bad

例外：当变量被 const 修饰时，"*” 无法跟随变量，此时也不要跟随类型。

const char * const VERSION = "V100";

建议3.12.2 引用类型"&“跟随变量名或者类型，不要两边都留有或者都没有空格

引用命名：&靠左靠右都可以，但是不要两边都有或者都没有空格。

int i = 8;

int& p = i;     // Good
int &p = i;     // Good
int*& rp = pi;  // Good，指针的引用，*& 一起跟随类型
int *&rp = pi;  // Good，指针的引用，*& 一起跟随变量名
int* &rp = pi;  // Good，指针的引用，* 跟随类型，& 跟随变量名

int & p = i;    // Bad
int&p = i;      // Bad

编译预处理

规则3.13.1 编译预处理的”#“统一放在行首，嵌套编译预处理语句时，”#“可以进行缩进

编译预处理的”#“统一放在行首，即使编译预处理的代码是嵌入在函数体中的，”#“也应该放在行首。

规则3.13.2 避免使用宏

宏会忽略作用域，类型系统以及各种规则，容易引发问题。应尽量避免使用宏定义，如果必须使用宏，要保证证宏名的唯一性。 在C++中，有许多方式来避免使用宏：

• 用const或enum定义易于理解的常量
• 用namespace避免名字冲突
• 用inline函数避免函数调用的开销
• 用template函数来处理多种类型

在文件头保护宏、条件编译、日志记录等必要场景中可以使用宏。

规则3.13.3 禁止使用宏来表示常量

宏是简单的文本替换，在预处理阶段完成，运行报错时直接报相应的值；跟踪调试时也是显示值，而不是宏名； 宏没有类型检查，不安全； 宏没有作用域。

规则3.13.4 禁止使用函数式宏

宏义函数式宏前，应考虑能否用函数替代。对于可替代场景，建议用函数替代宏。 函数式宏的缺点如下：

• 函数式宏缺乏类型检查，不如函数调用检查严格
• 宏展开时宏参数不求值，可能会产生非预期结果
• 宏没有独立的作用域
• 宏的技巧性太强，例如#的用法和无处不在的括号，影响可读性
• 在特定场景中必须用编译器对宏的扩展语法，如GCC的statement expression，影响可移植性
• 宏在预编译阶段展开后，在期后编译、链接和调试时都不可见；而且包含多行的宏会展开为一行。函数式宏难以调试、难以打断点，不利于定位问题
• 对于包含大量语句的宏，在每个调用点都要展开。如果调用点很多，会造成代码空间的膨胀

函数没有宏的上述缺点。但是，函数相比宏，最大的劣势是执行效率不高（增加函数调用的开销和编译器优化的难度）。 为此，可以在必要时使用内联函数。内联函数跟宏类似，也是在调用点展开。不同之处在于内联函数是在编译时展开。

内联函数兼具函数和宏的优点：

• 内联函数执行严格的类型检查
• 内联函数的参数求值只会进行一次
• 内联函数就地展开，没有函数调用的开销
• 内联函数比函数优化得更好

对于性能要求高的产品代码，可以考虑用内联函数代替函数。

例外： 在日志记录场景中，需要通过函数式宏保持调用点的文件名（FILE）、行号（LINE）等信息。

空格和空行

规则3.14.1 水平空格应该突出关键字和重要信息，避免不必要的留白

水平空格应该突出关键字和重要信息，每行代码尾部不要加空格。总体规则如下：

• if, switch, case, do, while, for等关键字之后加空格；
• 小括号内部的两侧，不要加空格；
• 大括号内部两侧有无空格，左右必须保持一致；
• 一元操作符（& * + ‐ ~ !）之后不要加空格；
• 二元操作符（= + ‐ < > * / % | & ^ <= >= == != ）左右两侧加空格
• 三目运算符（? :）符号两侧均需要空格
• 前置和后置的自增、自减（++ –）和变量之间不加空格
• 结构体成员操作符（. ->）前后不加空格
• 逗号(,)前面不加空格，后面增加空格
• 对于模板和类型转换(<>)和类型之间不要添加空格
• 域操作符(::)前后不要添加空格
• 冒号(:)前后根据情况来判断是否要添加空格

常规情况：

void Foo(int b) {  // Good：大括号前应该留空格

int i = 0;  // Good：变量初始化时，=前后应该有空格，分号前面不要留空格

int buf[BUF_SIZE] = {0};    // Good：大括号内两侧都无空格

函数定义和函数调用：

int result = Foo(arg1,arg2);
                    ^    // Bad: 逗号后面需要增加空格

int result = Foo( arg1, arg2 );
                 ^          ^  // Bad: 函数参数列表的左括号后面不应该有空格，右括号前面不应该有空格

指针和取地址

x = *p;     // Good：*操作符和指针p之间不加空格
p = &x;     // Good：&操作符和变量x之间不加空格
x = r.y;    // Good：通过.访问成员变量时不加空格
x = r->y;   // Good：通过->访问成员变量时不加空格

操作符：

x = 0;   // Good：赋值操作的=前后都要加空格
x = -5;  // Good：负数的符号和数值之前不要加空格
++x;     // Good：前置和后置的++/--和变量之间不要加空格
x--;

if (x && !y)  // Good：布尔操作符前后要加上空格，！操作和变量之间不要空格
v = w * x + y / z;  // Good：二元操作符前后要加空格
v = w * (x + z);    // Good：括号内的表达式前后不需要加空格

int a = (x < y) ? x : y;  // Good: 三目运算符， ？和：前后需要添加空格

循环和条件语句：

if (condition) {  // Good：if关键字和括号之间加空格，括号内条件语句前后不加空格
    ...
} else {           // Good：else关键字和大括号之间加空格
    ...
}

while (condition) {}   // Good：while关键字和括号之间加空格，括号内条件语句前后不加空格

for (int i = 0; i < someRange; ++i) {  // Good：for关键字和括号之间加空格，分号之后加空格
    ...
}

switch (condition) {  // Good: switch 关键字后面有1空格
    case 0:     // Good：case语句条件和冒号之间不加空格
        ...
        break;
    ...
    default:
        ...
        break;
}

模板和转换

// 尖括号(< and >) 不与空格紧邻, < 前没有空格, > 和 ( 之间也没有.
vector<string> x;
y = static_cast<char*>(x);

// 在类型与指针操作符之间留空格也可以, 但要保持一致.
vector<char *> x;

域操作符

std::cout;    // Good: 命名空间访问，不要留空格

int MyClass::GetValue() const {}  // Good: 对于成员函数定义，不要留空格

冒号

// 添加空格的场景

// Good: 类的派生需要留有空格
class Sub : public Base {
   
};

// 构造函数初始化列表需要留有空格
MyClass::MyClass(int var) : someVar_(var)
{
    DoSomething();
}

// 位域表示也留有空格
struct XX {
    char a : 4;    
    char b : 5;    
    char c : 4;
};

// 不添加空格的场景

// Good: 对于public:, private:这种类访问权限的冒号不用添加空格
class MyClass {
public:
    MyClass(int var);
private:
    int someVar_;
};

// 对于switch-case的case和default后面的冒号不用添加空格
switch (value)
{
    case 1:
        DoSomething();
        break;
    default:
        break;
}

注意：当前的集成开发环境（IDE）可以设置删除行尾的空格，请正确配置。

建议3.14.1 合理安排空行，保持代码紧凑

减少不必要的空行，可以显示更多的代码，方便代码阅读。下面有一些建议遵守的规则：

• 根据上下内容的相关程度，合理安排空行；
• 函数内部、类型定义内部、宏内部、初始化表达式内部，不使用连续空行
• 不使用连续 3 个空行，或更多
• 大括号内的代码块行首之前和行尾之后不要加空行，但namespace的大括号内不作要求。

int Foo()
{
    ...
}



int Bar()  // Bad：最多使用连续2个空行。
{
    ...
}


if (...) {
        // Bad：大括号内的代码块行首不要加入空行
    ...
        // Bad：大括号内的代码块行尾不要加入空行
}

int Foo(...)
{
        // Bad：函数体内行首不要加空行
    ...
}

类

规则3.15.1 类访问控制块的声明依次序是 public:, protected:, private:，缩进和 class 关键字对齐

class MyClass : public BaseClass {
public:      // 注意没有缩进
    MyClass();  // 标准的4空格缩进
    explicit MyClass(int var);
    ~MyClass() {}

    void SomeFunction();
    void SomeFunctionThatDoesNothing()
    {
    }

    void SetVar(int var) { someVar_ = var; }
    int GetVar() const { return someVar_; }

private:
    bool SomeInternalFunction();

    int someVar_;
    int someOtherVar_;
};

在各个部分中，建议将类似的声明放在一起, 并且建议以如下的顺序: 类型 (包括 typedef, using 和嵌套的结构体与类), 常量, 工厂函数, 构造函数, 赋值运算符, 析构函数, 其它成员函数, 数据成员。

规则3.15.2 构造函数初始化列表放在同一行或按四格缩进并排多行

// 如果所有变量能放在同一行:
MyClass::MyClass(int var) : someVar_(var)
{
    DoSomething();
}

// 如果不能放在同一行,
// 必须置于冒号后, 并缩进4个空格
MyClass::MyClass(int var)
    : someVar_(var), someOtherVar_(var + 1)  // Good: 逗号后面留有空格
{
    DoSomething();
}

// 如果初始化列表需要置于多行, 需要逐行对齐
MyClass::MyClass(int var)
    : someVar_(var),             // 缩进4个空格
      someOtherVar_(var + 1)
{ 
    DoSomething();
}

4 注释

一般的，尽量通过清晰的架构逻辑，好的符号命名来提高代码可读性；需要的时候，才辅以注释说明。 注释是为了帮助阅读者快速读懂代码，所以要从读者的角度出发，按需注释。

注释内容要简洁、明了、无二义性，信息全面且不冗余。

注释跟代码一样重要。 写注释时要换位思考，用注释去表达此时读者真正需要的信息。在代码的功能、意图层次上进行注释，即注释解释代码难以表达的意图，不要重复代码信息。 修改代码时，也要保证其相关注释的一致性。只改代码，不改注释是一种不文明行为，破坏了代码与注释的一致性，让阅读者迷惑、费解，甚至误解。

使用英文进行注释。

注释风格

在 C++ 代码中，使用 /* */和 // 都是可以的。 按注释的目的和位置，注释可分为不同的类型，如文件头注释、函数头注释、代码注释等等； 同一类型的注释应该保持统一的风格。

注意：本文示例代码中，大量使用 ‘//’ 后置注释只是为了更精确的描述问题，并不代表这种注释风格更好。

文件头注释

规则3.1 文件头注释必须包含版权许可

/*

• Copyright (c) 2020 XXX
• Licensed under the Apache License, Version 2.0 (the “License”);
• you may not use this file except in compliance with the License.
• You may obtain a copy of the License at *

• http://www.apache.org/licenses/LICENSE-2.0
  

*

• Unless required by applicable law or agreed to in writing, software
• distributed under the License is distributed on an “AS IS” BASIS,
• WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
• See the License for the specific language governing permissions and
• limitations under the License. */

函数头注释

规则4.3.1 公有（public）函数必须编写函数头注释

公有函数属于类对外提供的接口，调用者需要了解函数的功能、参数的取值范围、返回的结果、注意事项等信息才能正常使用。 特别是参数的取值范围、返回的结果、注意事项等都无法做到自注示，需要编写函数头注释辅助说明。

规则4.3.2 禁止空有格式的函数头注释

并不是所有的函数都需要函数头注释； 函数签名无法表达的信息，加函数头注释辅助说明;

函数头注释统一放在函数声明或定义上方，使用如下风格之一： 使用//写函数头

// 单行函数头
int Func1(void);

// 多行函数头
// 第二行
int Func2(void);

使用/* */写函数头

/* 单行函数头 */
int Func1(void);

/*
 * 另一种单行函数头
 */
int Func2(void);

/*
 * 多行函数头
 * 第二行
 */
int Func3(void);

函数尽量通过函数名自注释，按需写函数头注释。 不要写无用、信息冗余的函数头；不要写空有格式的函数头。

函数头注释内容可选，但不限于：功能说明、返回值，性能约束、用法、内存约定、算法实现、可重入的要求等等。 模块对外头文件中的函数接口声明，其函数头注释，应当将重要、有用的信息表达清楚。

例：

/*
 * 返回实际写入的字节数，-1表示写入失败
 * 注意，内存 buf 由调用者负责释放
 */
int WriteString(const char *buf, int len);

坏的例子：

/*
 * 函数名：WriteString
 * 功能：写入字符串
 * 参数：
 * 返回值：
 */
int WriteString(const char *buf, int len);

上面例子中的问题：

• 参数、返回值，空有格式没内容
• 函数名信息冗余
• 关键的 buf 由谁释放没有说清楚

代码注释

规则4.4.1 代码注释放于对应代码的上方或右边

规则4.4.2 注释符与注释内容间要有1空格；右置注释与前面代码至少1空格

代码上方的注释，应该保持对应代码一样的缩进。 选择并统一使用如下风格之一： 使用//

// 这是单行注释
DoSomething();

// 这是多行注释
// 第二行
DoSomething();

使用/*' '*/

/* 这是单行注释 */
DoSomething();

/*
 * 另一种方式的多行注释
 * 第二行
 */
DoSomething();

代码右边的注释，与代码之间，至少留1空格，建议不超过4空格。 通常使用扩展后的 TAB 键即可实现 1-4 空格的缩进。

选择并统一使用如下风格之一：

int foo = 100;  // 放右边的注释
int bar = 200;  /* 放右边的注释 */

右置格式在适当的时候，上下对齐会更美观。 对齐后的注释，离左边代码最近的那一行，保证1-4空格的间隔。 例：

const int A_CONST = 100;         /* 相关的同类注释，可以考虑上下对齐 */
const int ANOTHER_CONST = 200;   /* 上下对齐时，与左侧代码保持间隔 */

当右置的注释超过行宽时，请考虑将注释置于代码上方。

规则4.4.3 不用的代码段直接删除，不要注释掉

被注释掉的代码，无法被正常维护；当企图恢复使用这段代码时，极有可能引入易被忽略的缺陷。 正确的做法是，不需要的代码直接删除掉。若再需要时，考虑移植或重写这段代码。

这里说的注释掉代码，包括用 /* */ 和 //，还包括 #if 0， #ifdef NEVER_DEFINED 等等。

5 头文件

头文件职责

头文件是模块或文件的对外接口，头文件的设计体现了大部分的系统设计。 头文件中适合放置接口的声明，不适合放置实现（内联函数除外）。对于cpp文件中内部才需要使用的函数、宏、枚举、结构定义等不要放在头文件中。 头文件应当职责单一。头文件过于复杂，依赖过于复杂还是导致编译时间过长的主要原因。

建议5.1.1 每一个.cpp文件应有一个对应的.h文件，用于声明需要对外公开的类与接口

通常情况下，每个.cpp文件都有一个相应的.h，用于放置对外提供的函数声明、宏定义、类型定义等。 如果一个.cpp文件不需要对外公布任何接口，则其就不应当存在。 例外：程序的入口（如main函数所在的文件），单元测试代码，动态库代码。

示例:

// Foo.h

#ifndef FOO_H
#define FOO_H

class Foo {
public:
    Foo();
    void Fun();
   
private:
    int value_;
};

#endif

// Foo.cpp
#include "Foo.h"

namespace { // Good: 对内函数的声明放在.cpp文件的头部，并声明为匿名namespace或者static限制其作用域
    void Bar()
    {
    }
}

...

void Foo::Fun()
{
    Bar();
}

头文件依赖

规则5.2.1 禁止头文件循环依赖

头文件循环依赖，指 a.h 包含 b.h，b.h 包含 c.h，c.h 包含 a.h， 导致任何一个头文件修改，都导致所有包含了a.h/b.h/c.h的代码全部重新编译一遍。 而如果是单向依赖，如a.h包含b.h，b.h包含c.h，而c.h不包含任何头文件，则修改a.h不会导致包含了b.h/c.h的源代码重新编译。

头文件循环依赖直接体现了架构设计上的不合理，可通过优化架构去避免。

规则5.2.2 头文件必须编写#define保护，防止重复包含

为防止头文件被重复包含，所有头文件都应当使用 #define 保护；不要使用 #pragma once

定义包含保护符时，应该遵守如下规则： 1）保护符使用唯一名称； 2）不要在受保护部分的前后放置代码或者注释，文件头注释除外。

示例：假定timer模块的timer.h，其目录为timer/include/timer.h,应按如下方式保护：

#ifndef TIMER_INCLUDE_TIMER_H
#define TIMER_INCLUDE_TIMER_H
...
#endif

规则5.2.3 禁止通过声明的方式引用外部函数接口、变量

只能通过包含头文件的方式使用其他模块或文件提供的接口。 通过 extern 声明的方式使用外部函数接口、变量，容易在外部接口改变时可能导致声明和定义不一致。 同时这种隐式依赖，容易导致架构腐化。

不符合规范的案例：

// a.cpp内容

extern int Fun();   // Bad: 通过extern的方式使用外部函数

void Bar()
{
    int i = Fun();
    ...
}

// b.cpp内容

int Fun()
{
    // Do something
}

应该改为：

// a.cpp内容

#include "b.h"   // Good: 通过包含头文件的方式使用其他.cpp提供的接口

void Bar()
{
    int i = Fun();
    ...
}

// b.h内容

int Fun();

// b.cpp内容

int Fun()
{
    // Do something
}

例外，有些场景需要引用其内部函数，但并不想侵入代码时，可以 extern 声明方式引用。 如： 针对某一内部函数进行单元测试时，可以通过 extern 声明来引用被测函数； 当需要对某一函数进行打桩、打补丁处理时，允许 extern 声明该函数。

规则5.2.4 禁止在extern “C"中包含头文件

在 extern “C” 中包含头文件，有可能会导致 extern “C” 嵌套，部分编译器对 extern “C” 嵌套层次有限制，嵌套层次太多会编译错误。

在C，C++混合编程的情况下，在extern “C"中包含头文件，可能会导致被包含头文件的原有意图遭到破坏，比如链接规范被不正确地更改。

示例，存在a.h和b.h两个头文件：

// a.h内容

...
#ifdef __cplusplus
void Foo(int);
#define A(value) Foo(value)
#else
void A(int)
#endif

// b.h内容

...
#ifdef __cplusplus
extern "C" {
#endif

#include "a.h"
void B();

#ifdef __cplusplus
}
#endif

使用C++预处理器展开b.h，将会得到

extern "C" {
    void Foo(int);
    void B();
}

按照 a.h 作者的本意，函数 Foo 是一个 C++ 自由函数，其链接规范为 “C++"。 但在 b.h 中，由于 #include "a.h" 被放到了 extern "C" 的内部，函数 Foo 的链接规范被不正确地更改了。

例外： 如果在 C++ 编译环境中，想引用纯C的头文件，这些C头文件并没有 extern "C" 修饰。非侵入式的做法是，在 extern "C" 中去包含C头文件。

建议5.2.1尽量避免使用前置声明，而是通过#include来包含头文件

前置声明（forward declaration）通常指类、模板的纯粹声明，没伴随着其定义。

• 优点：
  1. 前置声明能够节省编译时间，多余的 #include 会迫使编译器展开更多的文件，处理更多的输入。
  2. 前置声明能够节省不必要的重新编译的时间。 #include 使代码因为头文件中无关的改动而被重新编译多次。
• 缺点：
  1. 前置声明隐藏了依赖关系，头文件改动时，用户的代码会跳过必要的重新编译过程。
  2. 前置声明可能会被库的后续更改所破坏。前置声明模板有时会妨碍头文件开发者变动其 API. 例如扩大形参类型，加个自带默认参数的模板形参等等。
  3. 前置声明来自命名空间 std:: 的 symbol 时，其行为未定义（在C++11标准规范中明确说明）。
  4. 前置声明了不少来自头文件的 symbol 时，就会比单单一行的 include 冗长。
  5. 仅仅为了能前置声明而重构代码（比如用指针成员代替对象成员）会使代码变得更慢更复杂。
  6. 很难判断什么时候该用前置声明，什么时候该用#include，某些场景下面前置声明和#include互换以后会导致意想不到的结果。

所以我们尽可能避免使用前置声明，而是使用#include头文件来保证依赖关系。

6 作用域

命名空间

建议6.1.1 对于cpp文件中不需要导出的变量，常量或者函数，请使用匿名namespace封装或者用static修饰

在C++ 2003标准规范中，使用static修饰文件作用域的变量，函数等被标记为deprecated特性，所以更推荐使用匿名namespace。

主要原因如下：

1. static在C++中已经赋予了太多的含义，静态函数成员变量，静态成员函数，静态全局变量，静态函数局部变量，每一种都有特殊的处理。
2. static只能保证变量，常量和函数的文件作用域，但是namespace还可以封装类型等。
3. 统一namespace来处理C++的作用域，而不需要同时使用static和namespace来管理。
4. static修饰的函数不能用来实例化模板，而匿名namespace可以。

但是不要在 .h 中使用中使用匿名namespace或者static。

// Foo.cpp

namespace {
    const int MAX_COUNT = 20;
    void InternalFun() {};
}

void Foo::Fun()
{
    int i = MAX_COUNT;
   
    InternalFun();
}

规则6.1.1 不要在头文件中或者#include之前使用using导入命名空间

说明：使用using导入命名空间会影响后续代码，易造成符号冲突，所以不要在头文件以及源文件中的#include之前使用using导入命名空间。 示例：

// 头文件a.h
namespace NamespaceA {
    int Fun(int);
}

// 头文件b.h
namespace NamespaceB {
    int Fun(int);
}

using namespace NamespaceB;

void G()
{
    Fun(1);
}

// 源代码a.cpp
#include "a.h"
using namespace NamespaceA;
#include "b.h"

void main()
{
    G(); // using namespace NamespaceA在#include “b.h”之前，引发歧义：NamespaceA::Fun，NamespaceB::Fun调用不明确
}

对于在头文件中使用using导入单个符号或定义别名，允许在模块自定义名字空间中使用，但禁止在全局名字空间中使用。

// foo.h

#include <fancy/string>
using fancy::string;  // Bad，禁止向全局名字空间导入符号

namespace Foo {
    using fancy::string;  // Good，可以在模块自定义名字空间中导入符号
    using MyVector = fancy::vector<int>;  // Good，C++11可在自定义名字空间中定义别名
}

全局函数和静态成员函数

建议6.2.1 优先使用命名空间来管理全局函数，如果和某个class有直接关系的，可以使用静态成员函数

说明：非成员函数放在名字空间内可避免污染全局作用域， 也不要用类+静态成员方法来简单管理全局函数。 如果某个全局函数和某个类有紧密联系， 那么可以作为类的静态成员函数。

如果你需要定义一些全局函数，给某个cpp文件使用，那么请使用匿名namespace来管理。

namespace MyNamespace {
    int Add(int a, int b);
}

class File {
public:
    static File CreateTempFile(const std::string& fileName);
};

全局常量和静态成员常量

建议6.3.1 优先使用命名空间来管理全局常量，如果和某个class有直接关系的，可以使用静态成员常量

说明：全局常量放在命名空间内可避免污染全局作用域， 也不要用类+静态成员常量来简单管理全局常量。 如果某个全局常量和某个类有紧密联系， 那么可以作为类的静态成员常量。

如果你需要定义一些全局常量，只给某个cpp文件使用，那么请使用匿名namespace来管理。

namespace MyNamespace {
    const int MAX_SIZE = 100;
}

class File {
public:
    static const std::string SEPARATOR;
};

全局变量

建议6.4.1 尽量避免使用全局变量，考虑使用单例模式

说明：全局变量是可以修改和读取的，那么这样会导致业务代码和这个全局变量产生数据耦合。

int g_counter = 0;

// a.cpp
g_counter++;

// b.cpp
g_counter++;

// c.cpp
cout << g_counter << endl;

使用单实例模式

class Counter {
public:
    static Counter& GetInstance()
    {
        static Counter counter;
        return counter;
    }  // 单实例实现简单举例
   
    void Increase()
    {
        value_++;
    }
   
    void Print() const
    {
        std::cout << value_ << std::endl;
    }

private:
    Counter() : value_(0) {}

private:
    int value_;
};

// a.cpp
Counter::GetInstance().Increase();

// b.cpp
Counter::GetInstance().Increase();

// c.cpp
Counter::GetInstance().Print();

实现单例模式以后，实现了全局唯一一个实例，和全局变量同样的效果，并且单实例提供了更好的封装性。

例外：有的时候全局变量的作用域仅仅是模块内部，这样进程空间里面就会有多个全局变量实例，每个模块持有一份，这种场景下是无法使用单例模式解决的。

7 类

构造，拷贝构造，赋值和析构函数

构造，拷贝，移动和析构函数提供了对象的生命周期管理方法：

• 构造函数（constructor）： X()
• 拷贝构造函数（copy constructor）：X(const X&)
• 拷贝赋值操作符（copy assignment）：operator=(const X&)
• 移动构造函数（move constructor）：X(X&&) C++11以后提供
• 移动赋值操作符（move assignment）：operator=(X&&) C++11以后提供
• 析构函数（destructor）：~X()

规则7.1.1 类的成员变量必须显式初始化

说明：如果类有成员变量，没有定义构造函数，又没有定义默认构造函数，编译器将自动生成一个构造函数，但编译器生成的构造函数并不会对成员变量进行初始化，对象状态处于一种不确定性。

例外：

• 如果类的成员变量具有默认构造函数，那么可以不需要显式初始化。

示例：如下代码没有构造函数，私有数据成员无法初始化：

class Message {
public:
    void ProcessOutMsg()
    {
        //…
    }

private:
    unsigned int msgID_;
    unsigned int msgLength_;
    unsigned char* msgBuffer_;
    std::string someIdentifier_;
};

Message message;   // message成员变量没有初始化
message.ProcessOutMsg();   // 后续使用存在隐患

// 因此，有必要定义默认构造函数，如下：
class Message {
public:
    Message() : msgID_(0), msgLength_(0), msgBuffer_(nullptr)
    {
    }

    void ProcessOutMsg()
    {
        // …
    }

private:
    unsigned int msgID_;
    unsigned int msgLength_;
    unsigned char* msgBuffer_;
    std::string someIdentifier_; // 具有默认构造函数，不需要显式初始化
};

建议7.1.1 成员变量优先使用声明时初始化（C++11）和构造函数初始化列表初始化

说明：C++11的声明时初始化可以一目了然的看出成员初始值，应当优先使用。如果成员初始化值和构造函数相关，或者不支持C++11，则应当优先使用构造函数初始化列表来初始化成员。相比起在构造函数体中对成员赋值，初始化列表的代码更简洁，执行性能更好，而且可以对const成员和引用成员初始化。

class Message {
public:
    Message() : msgLength_(0)  // Good，优先使用初始化列表
    {
        msgBuffer_ = nullptr;  // Bad，不推荐在构造函数中赋值
    }
   
private:
    unsigned int msgID_{0};  // Good，C++11中使用
    unsigned int msgLength_;
    unsigned char* msgBuffer_;
};

规则7.1.2 为避免隐式转换，将单参数构造函数声明为explicit

说明：单参数构造函数如果没有用explicit声明，则会成为隐式转换函数。 示例：

class Foo {
public:
    explicit Foo(const string& name): name_(name)
    {
    }
private:
    string name_;
};


void ProcessFoo(const Foo& foo){}

int main(void)
{
    std::string test = "test";
    ProcessFoo(test);  // 编译不通过
    return 0;
}

上面的代码编译不通过，因为ProcessFoo需要的参数是Foo类型，传入的string类型不匹配。

如果将Foo构造函数的explicit关键字移除，那么调用ProcessFoo传入的string就会触发隐式转换，生成一个临时的Foo对象。往往这种隐式转换是让人迷惑的，并且容易隐藏Bug，得到了一个不期望的类型转换。所以对于单参数的构造函数是要求explicit声明。

规则7.1.3 如果不需要拷贝构造函数、赋值操作符 / 移动构造函数、赋值操作符，请明确禁止

说明：如果用户不定义，编译器默认会生成拷贝构造函数和拷贝赋值操作符， 移动构造和移动赋值操作符（移动语义的函数C++11以后才有）。 如果我们不要使用拷贝构造函数，或者赋值操作符，请明确拒绝：

1. 将拷贝构造函数或者赋值操作符设置为private，并且不实现：

class Foo {
private:
    Foo(const Foo&);
    Foo& operator=(const Foo&);
};

2. 使用C++11提供的delete, 请参见后面现代C++的相关章节。

3. 推荐继承NoCopyable、NoMovable，禁止使用DISALLOW_COPY_AND_MOVE，DISALLOW_COPY，DISALLOW_MOVE等宏。

class Foo : public NoCopyable, public NoMovable {
};

NoCopyable和NoMovable的实现：

class NoCopyable {
public:
    NoCopyable() = default;
    NoCopyable(const NoCopyable&) = delete;
    NoCopyable& operator = (NoCopyable&) = delete;
};

class NoMovable {
public:
    NoMovable() = default;
    NoMovable(NoMovable&&) noexcept = delete;
    NoMovable& operator = (NoMovable&&) noexcept = delete;
};

规则7.1.4 拷贝构造和拷贝赋值操作符应该是成对出现或者禁止

拷贝构造函数和拷贝赋值操作符都是具有拷贝语义的，应该同时出现或者禁止。

// 同时出现
class Foo {
public:
    ...
    Foo(const Foo&);
    Foo& operator=(const Foo&);
    ...
};

// 同时default， C++11支持
class Foo {
public:
    Foo(const Foo&) = default;
    Foo& operator=(const Foo&) = default;
};

// 同时禁止, C++11可以使用delete
class Foo {
private:
    Foo(const Foo&);
    Foo& operator=(const Foo&);
};

规则7.1.5 移动构造和移动赋值操作符应该是成对出现或者禁止

在C++11中增加了move操作，如果需要某个类支持移动操作，那么需要实现移动构造和移动赋值操作符。

移动构造函数和移动赋值操作符都是具有移动语义的，应该同时出现或者禁止。

// 同时出现
class Foo {
public:
    ...
    Foo(Foo&&);
    Foo& operator=(Foo&&);
    ...
};

// 同时default， C++11支持
class Foo {
public:
    Foo(Foo&&) = default;
    Foo& operator=(Foo&&) = default;
};

// 同时禁止, 使用C++11的delete
class Foo {
public:
    Foo(Foo&&) = delete;
    Foo& operator=(Foo&&) = delete;
};

规则7.1.6 禁止在构造函数和析构函数中调用虚函数

说明：在构造函数和析构函数中调用当前对象的虚函数，会导致未实现多态的行为。 在C++中，一个基类一次只构造一个完整的对象。

示例：类Base是基类，Sub是派生类

class Base {                      
public:               
    Base();
    virtual void Log() = 0;    // 不同的派生类调用不同的日志文件
};

Base::Base()         // 基类构造函数
{
    Log();           // 调用虚函数Log
}                                                 

class Sub : public Base {      
public:
    virtual void Log();         
};

当执行如下语句： Sub sub; 会先执行Sub的构造函数，但首先调用Base的构造函数，由于Base的构造函数调用虚函数Log，此时Log还是基类的版本，只有基类构造完成后，才会完成派生类的构造，从而导致未实现多态的行为。 同样的道理也适用于析构函数。

规则7.1.7 多态基类中的拷贝构造函数、拷贝赋值操作符、移动构造函数、移动赋值操作符必须为非public函数或者为delete函数

如果报一个派生类对象直接赋值给基类对象，会发生切片，只拷贝或者移动了基类部分，损害了多态行为。 【反例】 如下代码中，基类没有定义拷贝构造函数或拷贝赋值操作符，编译器会自动生成这两个特殊成员函数， 如果派生类对象赋值给基类对象时就发生切片。可以将此例中的拷贝构造函数和拷贝赋值操作符声明为delete，编译器可检查出此类赋值行为。

class Base {                      
public:               
    Base() = default;
    virtual ~Base() = default;
    ...
    virtual void Fun() { std::cout << "Base" << std::endl;}
};

class Derived : public Base {
    ...
    void Fun() override { std::cout << "Derived" << std::endl; }
};

void Foo(const Base &base)
{
    Base other = base; // 不符合：发生切片
    other.Fun(); // 调用的时Base类的Fun函数
}

Derived d;
Foo(d); // 传入的是派生类对象

1. 将拷贝构造函数或者赋值操作符设置为private，并且不实现：

继承

规则7.2.1 基类的析构函数应该声明为virtual，不准备被继承的类需要声明为final

说明：只有基类析构函数是virtual，通过多态调用的时候才能保证派生类的析构函数被调用。

示例：基类的析构函数没有声明为virtual导致了内存泄漏。

class Base {
public:
    virtual std::string getVersion() = 0;
   
    ~Base()
    {
        std::cout << "~Base" << std::endl;
    }
};

class Sub : public Base {
public:
    Sub() : numbers_(nullptr)
    { 
    }
   
    ~Sub()
    {
        delete[] numbers_;
        std::cout << "~Sub" << std::endl;
    }
   
    int Init()
    {
        const size_t numberCount = 100;
        numbers_ = new (std::nothrow) int[numberCount];
        if (numbers_ == nullptr) {
            return -1;
        }
       
        ...
    }

    std::string getVersion()
    {
        return std::string("hello!");
    }
private:
    int* numbers_;
};

int main(int argc, char* args[])
{
    Base* b = new Sub();

    delete b;
    return 0;
}

चूंकि आधार वर्ग Base के डिस्ट्रक्टर को virtual के रूप में घोषित नहीं किया गया है, जब ऑब्जेक्ट को नष्ट किया जाता है, तो केवल बेस वर्ग के डिस्ट्रक्टर को कॉल किया जाता है, डेरिव्ड वर्ग Sub के डिस्ट्रक्टर को कॉल नहीं किया जाता है, जिससे मेमोरी लीक होती है। अपवाद: NoCopyable, NoMovable जैसे कोई भी व्यवहार नहीं होता है, बस पहचानकर्ता के रूप में उपयोग किए जाने वाले क्लास को अंतिम रूप से वर्चुअल डिस्ट्रक्टर या फाइनल की घोषणा नहीं करनी चाहिए।

नियम 7.2.2 वर्चुअल फंक्शन में डिफ़ॉल्ट पैरामीटर वैल्यू का उपयोग निषिद्ध करें

स्पष्टीकरण: C++ में, वर्चुअल फंक्शन को डायनामिक बाइंडिंग किया जाता है, लेकिन फंक्शन के डिफ़ॉल्ट पैरामीटर को संकलित समय पर स्थिर रूप से बाइंड किया जाता है। इसका अर्थ है कि आप अंततः एक फंक्शन को निष्पादित करते हैं जो डेरिव्ड वर्ग में परिभाषित होता है, लेकिन बेस वर्ग में डिफ़ॉल्ट पैरामीटर वैल्यू का उपयोग करता है। वर्चुअल फंक्शन के ओवरलोड होने पर, पैरामीटर घोषणा में असंगति के कारण उपयोगकर्ता को भ्रमित करने और इससे उत्पन्न समस्याओं को रोकने के लिए, सभी वर्चुअल फंक्शन में डिफ़ॉल्ट पैरामीटर वैल्यू की घोषणा करना निषिद्ध है। उदाहरण: वर्चुअल फंक्शन डिस्प्ले के डिफ़ॉल्ट पैरामीटर वैल्यू टेक्स्ट संकलन समय पर तय किए जाते हैं, न कि रनटाइम पर, जिससे बहुरूपता का उद्देश्य प्राप्त नहीं होता है:

class Base {
public:
    virtual void Display(const std::string& text = "Base!")
    {
        std::cout << text << std::endl;
    }
   
    virtual ~Base(){}
};

class Sub : public Base {
public:
    virtual void Display(const std::string& text  = "Sub!")
    {
        std::cout << text << std::endl;
    }
   
    virtual ~Sub(){}
};

int main()
{
    Base* base = new Sub();
    Sub* sub = new Sub();
  
    ...
   
    base->Display();  // प्रोग्राम आउटपुट: Base! और अपेक्षित आउटपुट: Sub!
    sub->Display();   // प्रोग्राम आउटपुट: Sub!
   
    delete base;
    delete sub;
    return 0;
};

नियम 7.2.3 विरासत में मिले गैर-वर्चुअल फंक्शन को फिर से परिभाषित करने की मनाही है

स्पष्टीकरण: क्योंकि गैर-वर्चुअल फंक्शन को डायनामिक बाइंडिंग के लिए नहीं बनाया गया है, केवल वर्चुअल फंक्शन को डायनामिक बाइंडिंग के लिए बनाया गया है: बेस क्लास के पॉइंटर के साथ ऑपरेशन करने से सही परिणाम प्राप्त किया जा सकता है।

उदाहरण:

class Base {
public:
    void Fun();
};

class Sub : public Base {
public:
    void Fun();
};

Sub* sub = new Sub();                    
Base* base = sub;

sub->Fun();    // सब क्लास के फंक्शन को कॉल करता है                 
base->Fun();   // पेरेंट क्लास के फंक्शन को कॉल करता है
//...

एकाधिक विरासत

वास्तविक विकास प्रक्रिया में एकाधिक विरासत के उपयोग के परिदृश्य कम हैं, क्योंकि एकाधिक विरासत के उपयोग में निम्नलिखित विशिष्ट समस्या हैं:

1. डेटा की डुप्लीकेशन और नाम द्विअर्थता के साथ हीरे की विरासत के कारण। इसलिए, C++ ने इस तरह की समस्याओं को हल करने के लिए virtual विरासत का आह्वान किया;
2. भले ही हीरे की विरासत न हो, कई पेरेंट क्लास के बीच नामों में टकराव हो सकता है, जिससे द्विअर्थता हो सकती है;
3. जब किसी सब क्लास को कई पेरेंट क्लास के तरीकों का विस्तार या पुनर्लेखन करने की आवश्यकता होती है, तो सब क्लास की ज़िम्मेदारी अस्पष्ट हो जाती है, अर्थ भ्रमित हो जाता है;
4. डेलीगेशन की तुलना में, विरासत एक व्हाइट-बॉक्स पुनः उपयोग है, अर्थात सब क्लास पेरेंट क्लास के protected सदस्यों तक पहुंच सकता है, जिससे अधिक मजबूत कपलिंग होती है। और एकाधिक विरासत, क्योंकि यह कई पेरेंट क्लास के साथ कपलिंग करती है, सिंगल रूट विरासत की तुलना में, इससे अधिक मजबूत कपलिंग रिश्ता होता है।

एकाधिक विरासत में निम्नलिखित लाभ हैं: एकाधिक विरासत प्रत्येक अलग इंटरफ़ेस को एक साथ जोड़कर कई इंटरफ़ेस या क्लास के असेंबल और पुनः उपयोग के लिए एक सरल संयोजन प्रदान करती है, scala भाषा के traits मिश्रण के समान।

इसलिए, एकाधिक विरासत के लिए केवल नीचे दिए गए कुछ मामलों में ही इसके उपयोग की अनुमति है।

सुझाव 7.3.1 इंटरफ़ेस विभाजन और बहुभूमिका संयोजन के लिए एकाधिक विरासत का उपयोग करें

यदि किसी क्लास को एकाधिक इंटरफ़ेस लागू करने की आवश्यकता है, तो एकाधिक विरासत के माध्यम से कई अलग इंटरफ़ेस को एक साथ जोड़ा जा सकता है।

class Role1 {};
class Role2 {};
class Role3 {};

class Object1 : public Role1, public Role2 {
    // ...
};

class Object2 : public Role2, public Role3 {
    // ...
};

C++ स्टैंडर्ड लाइब्रेरी में भी इसी तरह का उदाहरण है:

class basic_istream {};
class basic_ostream {};

class basic_iostream : public basic_istream, public basic_ostream {
 
};

ओवरलोड

ऑपरेटर ओवरलोड करने के लिए पर्याप्त कारण होना चाहिए, और ऑपरेटर के मूल अर्थ को नहीं बदलना चाहिए, उदाहरण के लिए ‘+’ ऑपरेटर का उपयोग घटाव के लिए नहीं करना चाहिए। ऑपरेटर ओवरलोडिंग से कोड अधिक स्पष्ट होता है, लेकिन इसके कुछ नुकसान भी हैं:

• सीधी धारणा को भ्रमित करना, इसके बारे में सोचना कि ऑपरेशन अंतर्निहित प्रकार की तरह ही उच्च प्रदर्शन वाला है, जो प्रदर्शन में कमी की संभावना को नज़रअंदाज़ करता है;
• खोज के समय समस्या का समाधान करना पर्याप्त रूप से स्पष्ट नहीं होता है, फंक्शन नाम से खोजना ऑपरेटर से खोजने की तुलना में स्पष्ट रूप से अधिक सुविधाजनक होता है।
• ऑपरेटर ओवरलोडिंग यदि व्यवहार परिभाषित नहीं होता है, जैसे ‘+’ ऑपरेटर का उपयोग घटाव के लिए किया जाता है, तो यह कोड को भ्रमित कर सकता है।
• असाइनमेंट ऑपरेटर के ओवरलोडिंग में छिपी हुई गहरी बग के लिए अंतर्निहित रूपांतरण लाया जाता है। =, == ऑपरेटर के बजाय Equals (), CopyFrom () जैसे फ़ंक्शन को परिभाषित किया जा सकता है।

8 फ़ंक्शन

फ़ंक्शन डिज़ाइन

नियम 8.1.1 लंबे फ़ंक्शन से बचें, फ़ंक्शन 50 पंक्तियों (गैर-खाली, गैर-टिप्पणी) से अधिक नहीं होना चाहिए

फ़ंक्शन एक स्क्रीन पर प्रदर्शित किया जा सकता है (50 पंक्तियों के भीतर), केवल एक ही काम करता है, और इसे अच्छी तरह से करता है।

लंबे फ़ंक्शन का मतलब यह होता है कि फ़ंक्शन की क्षमता एकल नहीं है, बहुत जटिल है, या बहुत अधिक विवरण प्रस्तुत करता है, जिसे और अधिक अमूर्त नहीं किया गया है।

अपवाद: कुछ एल्गोरिथ्म को लागू करने वाले फ़ंक्शन के लिए, एल्गोरिथ्म की एकजुटता और कार्य की व्यापकता के कारण, 50 पंक्तियों से अधिक हो सकता है।

भले ही एक लंबा फ़ंक्शन अच्छी तरह से काम करता है, एक बार किसी व्यक्ति द्वारा इसमें संशोधन किया जाए, तो नए समस्या के कारण हो सकता है, या गहरी बग का कारण बन सकता है, जिसे पता लगाना मुश्किल होता है। इसे अधिक संक्षिप्त और प्रबंधन के लिए आसान कई फ़ंक्शन में विभाजित करने का सुझाव दिया गया है, ताकि दूसरे लोगों के लिए कोड पढ़ना और संशोधित करना आसान हो।

इनलाइन फ़ंक्शन

सुझाव 8.2.1 इनलाइन फ़ंक्शन 10 पंक्तियों (गैर-खाली, गैर-टिप्पणी) से अधिक नहीं होना चाहिए

स्पष्टीकरण: इनलाइन फ़ंक्शन में सामान्य फ़ंक्शन की विशेषताएं होती हैं, यह सामान्य फ़ंक्शन से अलग है जिसका फ़ंक्शन कॉल के संदर्भ में होता है। सामान्य फ़ंक्शन को कॉल करते समय, प्रोग्राम एक्ज़ीक्यूशन को कॉल किए गए फ़ंक्शन में ले जाया जाता है, और फिर उस फ़ंक्शन में वापस आ जाता है जिसने इसे कॉल किया है; और इनलाइन फ़ंक्शन को कॉल करते समय, कॉल एक्सप्रेशन को इनलाइन फ़ंक्शन बॉडी द्वारा प्रतिस्थापित किया जाता है।

इनलाइन फ़ंक्शन केवल 1~10 पंक्तियों वाले छोटे फ़ंक्शन के लिए उपयुक्त है। बहुत सारे विवरण वाले बड़े फ़ंक्शन के लिए, फ़ंक्शन कॉल और रिटर्न का ओवरहेड अपेक्षाकृत तुच्छ होता है, और इनलाइन फ़ंक्शन के माध्यम से इसके लिए कोई आवश्यकता नहीं है, सामान्य तौर पर कंपाइलर इनलाइन विधि के बजाय सामान्य विधि के माध्यम से फ़ंक्शन कॉल का उपयोग करेगा।

यदि इनलाइन फ़ंक्शन में लूप, ब्रांच (स्विच), ट्राई-कैच आदि जैसे जटिल नियंत्रण संरचना शामिल हैं, तो आमतौर पर कंपाइलर उस फ़ंक्शन को सामान्य फ़ंक्शन के रूप में मानता है। वर्चुअल फ़ंक्शन, रिकर्सिव फ़ंक्शन को इनलाइन फ़ंक्शन बनाने के लिए इस्तेमाल नहीं किया जा सकता है।

फ़ंक्शन पैरामीटर

सुझाव 8.3.1 इनलाइन फ़ंक्शन 10 पंक्तियों (गैर-खाली, गैर-टिप्पणी) से अधिक नहीं होना चाहिए

स्पष्टीकरण: रेफ़रेंस पॉइंटर की तुलना में अधिक सुरक्षित होते हैं, क्योंकि वे निश्चित रूप से खाली नहीं होते हैं, और निश्चित रूप से अन्य लक्ष्य पर फिर से इशारा नहीं करते हैं; रेफ़रेंस गैर-कानूनी NULL पॉइंटर की जांच की आवश्यकता नहीं होती है।

यदि पुराने प्लेटफ़ॉर्म पर आधारित उत्पाद के लिए विकसित किया जा रहा है, तो मूल प्लेटफ़ॉर्म के ट्रीटमेंट के अनुसार प्राथमिकता दी जानी चाहिए। पैरामीटर को संशोधित न करने के लिए const का उपयोग करने से कोड रीडर को स्पष्ट रूप से पता चलता है कि पैरामीटर संशोधित नहीं किया जाएगा, जिससे कोड की पठनीयता बढ़ जाती है।

अपवाद: जब इनपुट पैरामीटर कंपाइल-टाइम लंबाई अज्ञात सरणी होती है, तो पॉइंटर का उपयोग रेफ़रेंस के बजाय किया जा सकता है।

सुझाव 8.3.2 मजबूत प्रकार पैरामीटर का उपयोग करें, void* के उपयोग से बचें

हालांकि विभिन्न भाषाओं के पास मजबूत प्रकार और कमज़ोर प्रकार के लिए अपने अपने विचार हैं, लेकिन आम तौर पर माना जाता है कि c/c++ मजबूत प्रकार वाली भाषा है, चूंकि हमारी भाषा मजबूत प्रकार की है, मजबूत प्रकार की शैली बनाए रखनी चाहिए। इसका लाभ यह है कि संकलक को संकलन चरण में प्रकार मिसमैच की जांच करने में मदद करने के लिए बहुत अधिक बल दिया जा सकता है।

मजबूत प्रकार का उपयोग करने से संकलक को हमारी मदद करने में मदद मिलती है, जैसे कि नीचे दिए गए कोड में फ़ंक्शन FooListAddNode के उपयोग पर ध्यान दें:

struct FooNode {
    struct List link;
    int foo;
};

struct BarNode {
    struct List link;
    int bar;
}

void FooListAddNode(void *node) // Bad: यहां पैरामीटर पास करने के लिए void * प्रकार का उपयोग किया जा रहा है
{
    FooNode *foo = (FooNode *)node;
    ListAppend(&g_FooList, &foo->link);
}

void MakeTheList()
{
    FooNode *foo = nullptr;
    BarNode *bar = nullptr;
    ...

    FooListAddNode(bar);        // Wrong: यहां मूल रूप से पैरामीटर foo पास करने का इरादा था, लेकिन bar गलती से पास हो गया, फिर भी इसके बारे में कोई त्रुटि नहीं आई
}

1. टेम्पलेट फ़ंक्शन का उपयोग प्रकार पैरामीटर के परिवर्तन के लिए किया जा सकता है।
2. बहुरूपता के लिए बेस क्लास पॉइंटर का उपयोग किया जा सकता है।

सुझाव 8.3.3 फ़ंक्शन के पैरामीटर 5 से अधिक नहीं होने चाहिए

फ़ंक्शन के अधिक पैरामीटर, इसे बाहरी परिवर्तनों के प्रति अधिक संवेदनशील बनाता है, जिससे रखरखाव कार्य प्रभावित होता है। फ़ंक्शन के अधिक पैरामीटर साथ ही परीक्षण कार्यभार में वृद्धि करता है।

यदि अधिक है, तो विचार करें:

• देखें कि क्या फ़ंक्शन विभाजित किया जा सकता है
• देखें कि क्या संबंधित पैरामीटर को एक साथ रखा जा सकता है, संरचना परिभाषित करें

9 C++ अन्य विशेषताएं

स्थिरांक और प्रारंभिककरण

अपरिवर्तित मूल्य को समझने, ट्रैक करने और विश्लेषण करने में आसानी होती है, इसलिए चर के बजाय स्थिरांक का उपयोग करना चाहिए, मूल्य परिभाषित करते समय, const को डिफ़ॉल्ट विकल्प के रूप में रखना चाहिए।

नियम 9.1.1 स्थिरांक को दर्शाने के लिए मैक्रो का उपयोग निषिद्ध है

स्पष्टीकरण: मैक्रो सरल टेक्स्ट प्रतिस्थापन है, जो प्रीप्रोसेसिंग चरण में पूरा होता है, रनटाइम त्रुटि होने पर सीधे मान को रिपोर्ट किया जाता है; डीबगिंग समय पर भी मैक्रो नाम के बजाय मान प्रदर्शित किया जाता है; मैक्रो में प्रकार जांच नहीं होती है, असुरक्षित है; मैक्रो में कोई क्षेत्र नहीं होता है।

#define MAX_MSISDN_LEN 20    // नहीं अच्छा

// C++ const स्थिरांक का उपयोग करना चाहिए
const int MAX_MSISDN_LEN = 20; // अच्छा

// C++11 या उसके बाद के संस्करण के लिए, constexpr का उपयोग किया जा सकता है
constexpr int MAX_MSISDN_LEN = 20;

सुझाव 9.1.1 संबंधित पूर्णांक स्थिरांक के एक सेट के लिए एन्यूमरेशन परिभाषित करें

स्पष्टीकरण: एन्यूमरेशन #define या const int की तुलना में अधिक सुरक्षित है। कंपाइलर यह जांचेगा कि क्या पैरामीटर मान एन्यूमरेशन मान रेंज के भीतर है, गलतियों को रोकने के लिए।

// अच्छा उदाहरण:
enum Week {
    SUNDAY,
    MONDAY,
    TUESDAY,
    WEDNESDAY,
    THURSDAY,
    FRIDAY,
    SATURDAY
};

enum Color {
    RED,
    BLACK,
    BLUE
};

void ColorizeCalendar(Week today, Color color);

ColorizeCalendar(BLUE, SUNDAY); // संकलन त्रुटि, पैरामीटर प्रकार गलत है

// खराब उदाहरण:
const int SUNDAY = 0;
const int MONDAY = 1;

const int BLACK  = 0;
const int BLUE   = 1;

bool ColorizeCalendar(int today, int color);
ColorizeCalendar(BLUE, SUNDAY); // त्रुटि नहीं आती है

जब एन्यूमरेशन मान को विशिष्ट संख्या में संगत करने की आवश्यकता होती है, तो यह घोषणा में स्पष्ट रूप से असाइन किया जाना चाहिए। अन्यथा, स्पष्ट रूप से असाइन करने की आवश्यकता नहीं है, ताकि डुप्लीकेशन असाइनमेंट से बचा जा सके, और रखरखाव (सदस्य जोड़ना, हटाना) का कार्यभार कम किया जा सके।

// अच्छा उदाहरण: S प्रोटोकॉल में डिवाइस पहचानकर्ता वैल्यू परिभाषित की गई है, जो डिवाइस प्रकार की पहचान करने के लिए उपयोग की जाती है
enum DeviceType {
    DEV_UNKNOWN = -1,
    DEV_DSMP = 0,
    DEV_ISMG = 1,
    DEV_WAPPORTAL = 2
};

कार्यक्रम के अंदर उपयोग किए जाने वाले, केवल वर्गीकरण के लिए उपयोग किए जाने वाले स्थिति में, स्पष्ट रूप से असाइन नहीं करना चाहिए।

// अच्छा उदाहरण: सत्र स्थिति को पहचानने के लिए कार्यक्रम में इस्तेमाल किया जाने वाला एन्यूमरेशन परिभाषा
enum SessionState {
    INIT,
    CLOSED,
    WAITING_FOR_RESPONSE
};

संभवतः डुप्लीकेशन एन्यूमरेशन मान से बचा जाना चाहिए, यदि इसकी आवश्यकता हो तो पहले से परिभाषित एन्यूमरेशन के साथ संशोधित किया जाना चाहिए।

enum RTCPType {
    RTCP_SR = 200,
    RTCP_MIN_TYPE = RTCP_SR,       
    RTCP_RR    = 201,
    RTCP_SDES  = 202,
    RTCP_BYE   = 203,
    RTCP_APP   = 204,
    RTCP_RTPFB = 205,
    RTCP_PSFB  = 206,
    RTCP_XR  = 207,
    RTCP_RSI = 208,
    RTCP_PUBPORTS = 209,
    RTCP_MAX_TYPE = RTCP_PUBPORTS 
};

नियम 9.1.2 शैतान अंकों का उपयोग निषिद्ध है

शैतान अंक का अर्थ है असमझ, असमझ में आने वाली संख्या।

शैतान अंक एक ब्लैक एंड व्हाइट कॉन्सेप्ट नहीं है, असमझ में आना भी डिग्री में होता है, जिसे स्वयं निर्धारित करने की आवश्यकता होती है। उदाहरण के लिए, अलग-अलग संदर्भों में संख्या 12 के मामले में स्थिति अलग-अलग होती है: type = 12; समझ में नहीं आता, लेकिन monthsCount = yearsCount * 12; समझ में आता है। 0 अंक कभी-कभी भी शैतान अंक होता है, जैसे कि status = 0; क्या स्थिति है, इसका पता नहीं चलता है।

समाधान के लिए तरीके: स्थानीय रूप से उपयोग की जाने वाली संख्या के लिए, स्पष्टीकरण के लिए टिप्पणी जोड़ सकते हैं कई जगहों पर उपयोग की जाने वाली संख्या के लिए, const स्थिरांक परिभाषित करना चाहिए, और सिंबल नामकरण स्व-टिप्पणी के माध्यम से।

निम्नलिखित परिस्थितियों को निषिद्ध किया गया है: संख्या के अर्थ की व्याख्या करने के लिए प्रतीक का उपयोग नहीं किया जाना चाहिए, जैसे const int ZERO = 0 सिंबल नामकरण ने इसके मान को सीमित किया, जैसे const int XX_TIMER_INTERVAL_300MS = 300, सीधे XX_TIMER_INTERVAL_MS का उपयोग करें जो इस स्थिरांक को टाइमर का समय अंतराल दर्शाता है।

नियम 9.1.3 स्थिरांक एकल ज़िम्मेदारी को बनाए रखना चाहिए

स्पष्टीकरण: एक स्थिरांक केवल एक विशिष्ट कार्य का प्रतिनिधित्व करता है, अर्थात एक स्थिरांक के कई उपयोग नहीं हो सकते हैं।

// अच्छा उदाहरण: प्रोटोकॉल A और B, मोबाइल स्टेशन आईडेंटिटी (MSISDN) की लंबाई 20 है।
const unsigned int A_MAX_MSISDN_LEN = 20;
const unsigned int B_MAX_MSISDN_LEN = 20;

// या विभिन्न नामस्थान का उपयोग करें:
namespace Namespace1 {
    const unsigned int MAX_MSISDN_LEN = 20;
}

namespace Namespace2 {
    const unsigned int MAX_MSISDN_LEN = 20;
}

नियम 9.1.4 गैर-POD ऑब्जेक्ट के लिए memcpy_s, memset_s का उपयोग करने पर प्रतिबंध लगाया गया है

स्पष्टीकरण: POD का पूरा नाम Plain Old Data है, यह C++ 98 स्टैंडर्ड (ISO/IEC 14882, पहला संस्करण, 1998-09-01) में पेश की गई अवधारणा है, POD प्रकार मुख्य रूप से int, char, float, double, enumeration, void, पॉइंटर आदि प्राथमिक प्रकार और एकत्रीकरण प्रकार को शामिल करता है, यह संलग्नक और ऑब्जेक्ट ओरिएंटेड विशेषताओं (जैसे उपयोगकर्ता परिभाषित निर्माण/असाइनमेंट/विघटन फ़ंक्शन, बेस क्लास, वर्चुअल फ़ंक्शन आदि) का उपयोग नहीं कर सकता है।

गैर-POD प्रकार जैसे कि गैर-एकत्रीकरण प्रकार के क्लास ऑब्जेक्ट के लिए, वर्चुअल फ़ंक्शन हो सकता है, मेमोरी लेआउट अनिश्चित होता है, कंपाइलर पर निर्भर करता है, यादृच्छिक मेमोरी कॉपी का दुरुपयोग गंभीर समस्या का कारण बन सकता है।

एकत्रीकरण प्रकार के क्लास के लिए भी, सीधे मेमोरी कॉपी और तुलना का उपयोग करना, सूचना छिपाने और डेटा संरक्षण के उद्देश्य को नष्ट करता है, memcpy_s, memset_s ऑपरेशन की अनुशंसा नहीं की जाती है।

POD प्रकार के विस्तृत विवरण के लिए अनुलग्नक देखें।

सुझाव 9.1.2 चर का उपयोग करते समय घोषित और प्रारंभ किया जाना चाहिए

स्पष्टीकरण: चर को प्रारंभिक मूल्य दिए बिना उपयोग किया जाना, एक आम निम्न-स्तरीय प्रोग्रामिंग त्रुटि है। उपयोग से पहले घोषित चर और साथ ही प्रारंभ करना, इस तरह की निम्न-स्तरीय त्रुटि से बचने के लिए बहुत आसान बनाता है।

फ़ंक्शन की शुरुआत में सभी चर को घोषित करना, फिर उनका उपयोग करना, स्कोप पूरे फ़ंक्शन लागूकरण को कवर करता है, इससे निम्नलिखित समस्या हो सकती है:

• प्रोग्राम को समझना और रखरखाव करना मुश्किल होता है: चर की परिभाषा और उपयोग अलग होता है।
• चर को उचित तरीके से प्रारंभ करना मुश्किल होता है: फ़ंक्शन की शुरुआत में, अक्सर पर्याप्त जानकारी नहीं होती है, जिससे प्रारंभीकरण किया जा सके, अक्सर किसी डिफ़ॉल्ट खाली मान (जैसे शून्य) का उपयोग किया जाता है, जो आम तौर पर एक बेकार है, यदि चर को उसके पहले प्रभावी मान से पहले उपयोग किया जाता है, तो यह त्रुटि का कारण बन सकता है।

चर स्कोप की न्यूनतमीकरण के सिद्धांत और निकटतम घोषणा के सिद्धांत का पालन करते हुए, कोड को पढ़ने में आसान बनाता है, चर के प्रकार और प्रारंभिक मान को समझने में मदद करता है। विशेष रूप से, प्रारंभिककरण के बजाय घोषणा के लिए इनिशियलाइज़ेशन के उपयोग की अनुशंसा की जाती है।

// खराब उदाहरण: घोषणा और प्रारंभिककरण अलग हैं
string name;        // घोषणा के समय प्रारंभिक मान नहीं दिया: डिफ़ॉल्ट कंस्ट्रक्टर को कॉल किया गया
name = "zhangsan";  // फिर से असाइनमेंट ऑपरेटर फ़ंक्शन को कॉल किया गया; घोषणा और परिभाषा अलग-अलग स्थानों पर हैं, समझना मुश्किल है

// अच्छा उदाहरण: घोषणा और प्रारंभिककरण एकीकृत हैं, समझने में आसान
string name("zhangsan");  // कंस्ट्रक्टर को कॉल किया गया

अभिव्यक्ति

नियम 9.2.1 चर वृद्धि या घटाव ऑपरेशन वाले अभिव्यक्ति में उस चर के पुनः उपयोग पर प्रतिबंध लगाया गया है

चर वृद्धि या घटाव ऑपरेशन वाले अभिव्यक्ति में, यदि उस चर का उपयोग फिर से किया जाता है, तो परिणाम C++ स्टैंडर्ड में स्पष्ट रूप से परिभाषित नहीं है। विभिन्न कंपाइलर या एक ही कंपाइलर के विभिन्न संस्करण के लिए अलग-अलग अमल हो सकता है। बेहतर पोर्टेबिलिटी के लिए, मानक द्वारा परिभाषित ऑपरेशन ऑर्डर पर कोई भी मान्यता नहीं करनी चाहिए।

ध्यान दें, ऑपरेशन ऑर्डर की समस्या को हल करने के लिए कोष्ठक का उपयोग नहीं किया जा सकता है, क्योंकि यह प्राथमिकता की समस्या नहीं है।

उदाहरण:

x = b[i] + i++; // Bad: b[i] ऑपरेशन और i++, ऑपरेशन का क्रम स्पष्ट नहीं है।

सही लिखने का तरीका यह है कि स्वयं वृद्धि या घटाव ऑपरेशन को एक पंक्ति में रखें:

x = b[i] + i;
i++;            // Good: एक अलग पंक्ति में

फ़ंक्शन पैरामीटर

Func(i++, i);   // Bad: दूसरा पैरामीटर पास करते समय, यह निश्चित नहीं है कि स्वयं वृद्धि ऑपरेशन हुआ है या नहीं

सही लिखने का तरीका

i++;            // Good: एक अलग पंक्ति में
x = Func(i, i);

नियम 9.2.2 switch स्टेटमेंट में default शाखा होनी चाहिए

अधिकांश मामलों में, switch स्टेटमेंट में default शाखा होनी चाहिए, ताकि छूटी हुई case लेबल प्रोसेसिंग के लिए एक डिफ़ॉल्ट प्रोसेसिंग व्यवहार हो।

विशेष मामला: यदि switch कंडीशन वेरिएबल एन्यूमरेशन प्रकार है, और case शाखा ने सभी मान को कवर किया है, तो default शाखा प्रोसेसिंग जोड़ना कुछ बेमानी हो सकता है। आधुनिक कंपाइलर में यह जांचने की क्षमता होती है कि क्या कोई एन्यूमरेशन मान switch स्टेटमेंट में छूट गया है, और इसके लिए संबंधित warning दिखाई दे सकती है।

enum Color {
    RED = 0,
    BLUE
};

// क्योंकि switch कंडीशन वेरिएबल एन्यूमरेशन है, इसलिए default शाखा जोड़ने की ज़रूरत नहीं है
switch (color) {
    case RED:
        DoRedThing();
        break;
    case BLUE:
        DoBlueThing();
        ...
        break;
}

सुझाव 9.2.1 अभिव्यक्ति की तुलना में, बाईं ओर बदलने वाली ओर झुकाव और दाईं ओर स्थिर ओर झुकाव होना चाहिए

जब चर की तुलना स्थिरांक से की जाती है, यदि स्थिरांक बाईं ओर है, जैसे कि if (MAX == v) पढ़ने में असहज होता है, और if (MAX > v) समझने में और भी मुश्किल होता है। मानव पठन और अभिव्यक्ति की आदत के अनुसार, स्थिरांक को दाईं ओर रखना चाहिए। इसे इस तरह लिखा जा सकता है:

if (value == MAX) {
 
}

if (value < MAX) {
 
}

इसमें विशेष मामले हैं, जैसे कि: if (MIN < value && value < MAX) को इंटरवल के रूप में दर्शाने के लिए, पहले आधे भाग में स्थिरांक बाईं ओर होता है।

स्थिरांक को बाईं ओर रखने के लिए चिंता न करें, क्योंकि if (value = MAX) में संकलन चेतावनी होगी, अन्य स्थिर जांच उपकरण भी त्रुटि दिखाएंगे। लेखनी की गलती की समस्या को हल करने के लिए उपकरणों का उपयोग करें, कोड को पठनीयता पहले होना चाहिए।

सुझाव 9.2.2 ऑपरेटर की प्राथमिकता को स्पष्ट करने के लिए कोष्ठक का उपयोग करें

ऑपरेटर की प्राथमिकता को स्पष्ट करने के लिए कोष्ठक का उपयोग करें, डिफ़ॉल्ट प्राथमिकता के कारण डिज़ाइन विचारों से असहमति के कारण प्रोग्राम त्रुटि होने से बचें; साथ ही कोड को और अधिक स्पष्ट और पठनीय बनाता है, हालांकि बहुत सारे कोष्ठक इसे कम पठनीय बनाते हैं। नीचे कोष्ठक के उपयोग के लिए सुझाव दिए गए हैं।

• दो या अधिक ऑपरेटर, यदि विभिन्न ऑपरेटर शामिल हैं, तो कोष्ठक का उपयोग किया जाना चाहिए

x = a + b + c;         /* ऑपरेटर एक ही हैं, कोष्ठक की आवश्यकता नहीं है */
x = Foo(a + b, c);     /* अभिव्यक्ति के दोनों तरफ अल्पविराम, कोष्ठक की आवश्यकता नहीं है */
x = 1 << (2 + 3);      /* विभिन्न ऑपरेटर, कोष्ठक की आवश्यकता है */
x = a + (b / 5);       /* विभिन्न ऑपरेटर, कोष्ठक की आवश्यकता है */
x = (a == b) ? a : (a – b);    /* विभिन्न ऑपरेटर, कोष्ठक की आवश्यकता है */

प्रकार परिवर्तन

प्रकार शाखा का उपयोग करके व्यवहार को अनुकूलित करने से बचें: प्रकार शाखा के द्वारा व्यवहार को अनुकूलित करना त्रुटिपूर्ण होता है, यह C++ में C कोड लिखने का स्पष्ट संकेत है। यह एक लचीला नहीं है, और नया प्रकार जोड़ने के लिए, यदि आपने सभी शाखाओं को संशोधित करने के बारे में भूल गए, तो कंपाइलर आपको बताएगा नहीं। टेम्पलेट और वर्चुअल फ़ंक्शन का उपयोग करें, ताकि प्रकार स्वयं बजाय उन्हें कॉल करने वाले कोड के द्वारा व्यवहार निर्धारित किया जा सके।

प्रकार परिवर्तन के उपयोग से बचने की अनुशंसा की जाती है, हम अपने कोड के प्रकार डिज़ाइन पर विचार करना चाहिए कि प्रत्येक डेटा का प्रकार क्या है, न कि प्रकार परिवर्तन के अत्यधिक उपयोग के द्वारा समस्या का समाधान करना चाहिए। जब हम किसी बुनियादी प्रकार का डिज़ाइन करते हैं, तो इस पर विचार करें:

• यह हस्ताक्षरित है या नहीं
• float या double के लिए उपयुक्त है
• int8, int16, int32 या int64 का उपयोग करना है, पूर्णांक की लंबाई निर्धारित करना है

हालांकि हम प्रकार परिवर्तन के उपयोग पर प्रतिबंध नहीं लगा सकते हैं, क्योंकि C++ एक मशीन प्रोग्रामिंग भाषा है, जिसमें पॉइंटर पते शामिल हैं, और हम विभिन्न तीसरे पक्ष या निचले स्तर के API के साथ बातचीत करते हैं, उनका प्रकार डिज़ाइन उचित नहीं हो सकता है, इस अनुकूलन प्रक्रिया में प्रकार परिवर्तन का उपयोग करना आसान हो जाता है।

अपवाद: किसी फ़ंक्शन को कॉल करते समय, यदि हम फ़ंक्शन के परिणाम को संभालना नहीं चाहते हैं, तो सबसे पहले यह विचार करें कि क्या यह आपका सबसे अच्छा विकल्प है। यदि वास्तव में फ़ंक्शन के रिटर्न मान को संभालना नहीं चाहते हैं, तो इसे हल करने के लिए (void) परिवर्तन का उपयोग किया जा सकता है।

नियम 9.3.1 यदि प्रकार परिवर्तन का उपयोग करने का निश्चय है, तो C++ द्वारा प्रदान किए गए प्रकार परिवर्तन का उपयोग करें, C प्रकार परिवर्तन का उपयोग नहीं करें

स्पष्टीकरण:

C++ द्वारा प्रदान किए गए प्रकार परिवर्तन में C प्रकार परिवर्तन की तुलना में अधिक लक्ष्यित परिवर्तन होता है, जो अधिक पठनीय है, और अधिक सुरक्षित है, C++ द्वारा प्रदान किए गए परिवर्तन में शामिल हैं:

• प्रकार परिवर्तन:

1. dynamic_cast: मुख्य रूप से विरासत प्रणाली में नीचे की ओर कनवर्ट करने के लिए उपयोग किया जाता है, dynamic_cast में प्रकार जांच की क्षमता होती है, कृपया आधार क्लास और डेरिव्ड क्लास के डिज़ाइन पर ध्यान दें, dynamic_cast के उपयोग से बचें।
2. static_cast: और C प्रकार परिवर्तन समान है, मान के बल असाइनमेंट के लिए किया जा सकता है, या ऊपर की ओर कनवर्ट (डेरिव्ड क्लास के पॉइंटर या रेफ़रेंस को बेस क्लास के पॉइंटर या रेफ़रेंस में कनवर्ट किया जा सकता है)। इस परिवर्तन का उपयोग अक्सर बहु-विरासत द्वारा लाए गए प्रकार विवाद को दूर करने के लिए किया जाता है, यह अपेक्षाकृत सुरक्षित है। यदि यह शुद्ध अंकगणित परिवर्तन है, तो ब्रेस इनिशियलाइज़ेशन के तरीके का उपयोग करने की अनुशंसा की जाती है।
3. reinterpret_cast: गैर-संबंधित प्रकार के परिवर्तन के लिए उपयोग किया जाता है। reinterpret_cast कंपाइलर को किसी प्रकार के ऑब्जेक्ट के मेमोरी को फिर से व्याख्या करने के लिए मजबूर करता है, जो एक अन्य प्रकार में है, यह एक असुरक्षित परिवर्तन है, कृपया reinterpret_cast के उपयोग को न्यूनतम करने की अनुशंसा की जाती है।
4. const_cast: ऑब्जेक्ट के const गुण को हटाने के लिए उपयोग किया जाता है, जिससे ऑब्जेक्ट को संशोधित किया जा सकता है, जिससे डेटा की अपरिवर्तनीयता नष्ट हो जाती है, कृपया const_cast के उपयोग को न्यूनतम करने की अनुशंसा की जाती है।

• अंकगणित परिवर्तन: (C++11 के बाद से समर्थित) उस अंकगणित परिवर्तन के लिए, जिसमें प्रकार जानकारी खो नहीं होती है, जैसे float से double, int32 से int64 का परिवर्तन, ब्रेस इनिशियलाइज़ेशन के तरीके का उपयोग करने की अनुशंसा की जाती है।

  double d{ someFloat };
  int64_t i{ someInt32 };

सुझाव 9.3.1 dynamic_cast के उपयोग से बचें

1. dynamic_cast C++ के RTTI पर निर्भर करता है, जो कंप्यूटर प्रोग्रामर को रनटाइम पर C++ क्लास ऑब्जेक्ट के प्रकार को पहचानने में मदद करता है।
2. dynamic_cast की उपस्थिति आमतौर पर हमारे बेस क्लास और डेरिव्ड क्लास डिज़ाइन में समस्या दिखाती है, डेरिव्ड क्लास बेस क्लास के अनुबंध को तोड़ता है, जिसके कारण dynamic_cast के द्वारा डेरिव्ड क्लास में कनवर्ट करके विशेष हैंडलिंग करने की आवश्यकता होती है, इस समय डेरिव्ड क्लास डिज़ाइन में सुधार करने की अनुशंसा की जाती है, न कि dynamic_cast के द्वारा समस्या का समाधान करने की।

सुझाव 9.3.2 reinterpret_cast के उपयोग से बचें

स्पष्टीकरण: reinterpret_cast गैर-संबंधित प्रकार के परिवर्तन के लिए उपयोग किया जाता है। reinterpret_cast किसी प्रकार के ऑब्जेक्ट को बल असाइनमेंट करके दूसरे प्रकार में कनवर्ट करने का प्रयास करता है, जो प्रकार की सुरक्षा और विश्वसनीयता को नष्ट करता है, यह एक असुरक्षित परिवर्तन है। विभिन्न प्रकारों के बीच परिवर्तन को न्यूनतम करने की अनुशंसा की जाती है।

सुझाव 9.3.3 const_cast के उपयोग से बचें

स्पष्टीकरण: const_cast ऑब्जेक्ट के const और volatile गुणों को हटाने के लिए उपयोग किया जाता है।

const_cast द्वारा कनवर्ट किए गए पॉइंटर या रेफ़रेंस का उपयोग करके const ऑब्जेक्ट को संशोधित करना, व्यवहार परिभाषित नहीं है।

// खराब उदाहरण
const int i = 1024;
int* p = const_cast<int*>(&i);
*p = 2048;      // परिभाषित नहीं है

// खराब उदाहरण
class Foo {
public:
    Foo() : i(3) {}

    void Fun(int v)
    {
        i = v;
    }

private:
    int i;
};

int main(void)
{
    const Foo f;
    Foo* p = const_cast<Foo*>(&f);
    p->Fun(8);  // परिभाषित नहीं है
}

संसाधन आवंटन और मुक्ति

नियम 9.4.1 एकल ऑब्जेक्ट के लिए डिलीट, एरे ऑब्जेक्ट के लिए डिलीट [] का उपयोग करें

स्पष्टीकरण: एकल ऑब्जेक्ट के लिए डिलीट का उपयोग करें, एरे ऑब्जेक्ट के लिए डिलीट [] का उपयोग करें, कारण:

• new को कॉल करने में शामिल कार्य: सिस्टम से मेमोरी का एक टुकड़ा अनुरोध करना, और इस प्रकार के कंस्ट्रक्टर को कॉल करना।
• new[n] को कॉल करने में शामिल कार्य: n ऑब्जेक्ट्स के लिए उपयुक्त मेमोरी आवंटित करना, और प्रत्येक ऑब्जेक्ट के लिए उसके कंस्ट्रक्टर को कॉल करना।
• डिलीट को कॉल करने में शामिल कार्य: पहले संबंधित डिस्ट्रक्टर को कॉल करना, फिर मेमोरी को सिस्टम में वापस करना।
• डिलीट [] को कॉल करने में शामिल कार्य: प्रत्येक ऑब्जेक्ट के लिए डिस्ट्रक्टर को कॉल करना, फिर सभी मेमोरी को मुक्त करना।

यदि new और डिलीट का फॉर्मेट मेल नहीं खाता है, तो परिणाम अज्ञात है। गैर-क्लास प्रकार के लिए, new और डिलीट कंस्ट्रक्टर और डिस्ट्रक्टर को कॉल नहीं करते हैं।

गलत लिखने का तरीका:

const int MAX_ARRAY_SIZE = 100;
int* numberArray = new int[MAX_ARRAY_SIZE];
...
delete numberArray;
numberArray = nullptr;

सही लिखने का तरीका:

const int MAX_ARRAY_SIZE = 100;
int* numberArray = new int[MAX_ARRAY_SIZE];
...
delete[] numberArray;
numberArray = nullptr;

सुझाव 9.4.1 RAII विशेषता का उपयोग डायनामिक आवंटन के लिए ट्रैकिंग में मदद के लिए करें

स्पष्टीकरण: RAII “संसाधन अधिग्रहण इनिशियलाइज़ेशन है” (Resource Acquisition Is Initialization) का संक्षिप्त रूप है, यह ऑब्जेक्ट जीवनकाल का उपयोग करके प्रोग्राम संसाधनों (जैसे मेमोरी, फ़ाइल हैंडल, नेटवर्क कनेक्शन, म्यूटेक्स आदि) को नियंत्रित करने की एक सरल तकनीक है।

RAII का सामान्य तरीका यह है: ऑब्जेक्ट कंस्ट्रक्शन के दौरान संसाधन प्राप्त करना, फिर ऑब्जेक्ट के जीवनकाल के भीतर संसाधनों के लिए पहुंच नियंत्रित करना जिससे ऑब्जेक्ट के जीवनकाल के भीतर संसाधनों को प्रभावी रूप से बनाए रखा जा सके, अंत में ऑब्जेक्ट डिस्ट्रक्शन के दौरान संसाधनों को मुक्त करना। इस प्रक्रिया में दो बड़े लाभ हैं:

• हमें संसाधनों को स्पष्ट रूप से मुक्त करने की आवश्यकता नहीं है।
• ऑब्जेक्ट द्वारा आवश्यक संसाधन ऑब्जेक्ट के जीवनकाल के भीतर प्रभावी रूप से बने रहते हैं। इस प्रकार, संसाधन प्रभावशीलता की जांच करने की आवश्यकता नहीं है, जिससे तर्क सरल होता है और दक्षता में सुधार होता है।

उदाहरण: RAII का उपयोग करके म्यूटेक्स संसाधनों को स्पष्ट रूप से मुक्त किए बिना।

class LockGuard {
public:
    LockGuard(const LockType& lockType): lock_(lockType)
    {
        lock_.Acquire();
    }
   
    ~LockGuard()
    {
        lock_.Release();
    }
   
private:
    LockType lock_;
};


bool Update()
{
    LockGuard lockGuard(mutex);
    if (...) {
        return false;
    } else {
        // डेटा को संचालित करें
    }
   
    return true;
}

स्टैंडर्ड लाइब्रेरी

STL स्टैंडर्ड टेम्पलेट लाइब्रेरी का उपयोग विभिन्न उत्पादों में अलग-अलग होता है, यहां कुछ मूल नियम और सुझाव दिए गए हैं, जिनका उपयोग विभिन्न टीमों द्वारा संदर्भ के लिए किया जा सकता है।

नियम 9.5.1 std::string के c_str() द्वारा वापस किए गए पॉइंटर को सहेजना निषिद्ध है

स्पष्टीकरण: C++ स्टैंडर्ड में string::c_str() पॉइंटर के लिए स्थायी रूप से मान्य होने की पुष्टि नहीं की गई है, इसलिए विशिष्ट STL अमल पूरी तरह से string::c_str() को कॉल करते समय एक अस्थायी स्टोरेज क्षेत्र वापस कर सकता है और इसे जल्दी से मुक्त कर सकता है। इसलिए पोर्टेबिलिटी को सुनिश्चित करने के लिए, string::c_str() के परिणाम को सहेजना नहीं चाहिए, और इसकी आवश्यकता होने पर सीधे कॉल करना चाहिए।

उदाहरण:

void Fun1()
{
    std::string name = "demo";
    const char* text = name.c_str();  // एक्सप्रेशन के समाप्त होने के बाद, name का जीवनकाल अभी भी है, पॉइंटर वैध है

    // यदि मध्य में string के गैर-const सदस्य फ़ंक्शन को कॉल किया जाता है, जिससे string में परिवर्तन होता है, जैसे operator[], begin() आदि
    // इसके कारण text की सामग्री उपलब्ध नहीं हो सकती है, या मूल स्ट्रिंग नहीं हो सकती है
    name = "test";
    name[1] = '2';

    // text पॉइंटर का उपयोग करने के बाद, इसकी स्ट्रिंग सामग्री "demo" नहीं होती है
}

void Fun2()
{
    std::string name = "demo";
    std::string test = "test";
    const char* text = (name + test).c_str(); // एक्सप्रेशन के समाप्त होने के बाद, + ऑपरेटर द्वारा उत्पन्न अस्थायी ऑब्जेक्ट को मुक्त कर दिया जाता है, पॉइंटर अमान्य हो जाता है

    // text पॉइंटर का उपयोग करने के बाद, यह अब वैध मेमोरी स्पेस की ओर इशारा नहीं करता है
}

अपवाद: कुछ प्रदर्शन के लिए बहुत उच्च आवश्यकताओं वाले कोड में, जिन्हें केवल const char* प्रकार के इनपुट पैरामीटर को स्वीकार करने वाले फ़ंक्शन के अनुकूलन के लिए, पॉइंटर को अस्थायी रूप से सहेजा जा सकता है। लेकिन स्ट्रिंग ऑब्जेक्ट का जीवनकाल पॉइंटर के जीवनकाल से लंबा होना चाहिए, और सुनिश्चित करना चाहिए कि पॉइंटर के जीवनकाल के भीतर स्ट्रिंग ऑब्जेक्ट को संशोधित नहीं किया गया है।

सुझाव 9.5.1 char* के बजाय std::string का उपयोग करें

स्पष्टीकरण: string का उपयोग char* के बजाय करने में कई लाभ हैं, जैसे:

1. अंतिम ‘\0’ के बारे में सोचने की आवश्यकता नहीं है;
2. +, =, == आदि ऑपरेटर और अन्य स्ट्रिंग ऑपरेशन फ़ंक्शन का सीधे उपयोग किया जा सकता है;
3. मेमोरी आवंटन ऑपरेशन की आवश्यकता नहीं है, जिससे स्पष्ट new/delete और इससे उत्पन्न त्रुटि से बचा जा सके;

ध्यान दें कि कुछ stl अमल में string लिखने-समय-पर-कॉपी रणनीति पर आधारित होता है, जिससे 2 समस्या होती है, एक तो यह है कि कुछ संस्करणों के लिखने-समय-पर-कॉपी रणनीति थ्रेड-सुरक्षित नहीं है, जिससे मल्टी-थ्रेडिंग वातावरण में प्रोग्राम क्रैश हो सकता है; दूसरा, जब डायनामिक लिंक लाइब्रेरी के साथ पारित किए गए लिखने-समय-पर-कॉपी रणनीति वाले string के साथ बातचीत की जाती है, तो डायनामिक लिंक लाइब्रेरी के अनलोड होने पर रेफ़रेंस काउंट कम नहीं होने के कारण लटकता हुआ पॉइंटर हो सकता है। इसलिए, एक विश्वसनीय stl अमल का चयन करना प्रोग्राम के स्थिर होने के लिए बहुत महत्वपूर्ण है।

अपवाद: जब तीसरे पक्ष या अन्य लाइब्रेरी API के साथ काम करते हैं, तो पहले से परिभाषित इंटरफ़ेस के लिए, केवल char* का उपयोग किया जा सकता है। लेकिन इंटरफ़ेस को कॉल करने से पहले string का उपयोग किया जा सकता है, इंटरफ़ेस को कॉल करते समय string::c_str() का उपयोग करके चरित्र पॉइंटर प्राप्त किया जा सकता है। जब स्टैक पर चरित्र सरणी को बफर के रूप में आवंटित किया जाता है, तो चरित्र सरणी को सीधे परिभाषित किया जा सकता है, string का उपयोग नहीं किया जाना चाहिए, और vector जैसे कंटेनर का उपयोग करने की भी आवश्यकता नहीं है।

नियम 9.5.2 auto_ptr का उपयोग निषिद्ध है

स्पष्टीकरण: std::auto_ptr में एक छिपा हुआ स्वामित्व स्थानांतरण व्यवहार होता है, जैसा कि नीचे दिया गया कोड:

auto_ptr<T> p1(new T);
auto_ptr<T> p2 = p1;

जब दूसरी पंक्ति के कथन को निष्पादित किया जाता है, तो p1 अब पहली पंक्ति में आवंटित ऑब्जेक्ट की ओर इशारा नहीं करता है, बल्कि nullptr बन जाता है। इसीलिए, auto_ptr को विभिन्न मानक कंटेनर में रखा नहीं जा सकता है। स्वामित्व स्थानांतरण व्यवहार आमतौर पर अपेक्षित परिणाम नहीं होता है। उन स्थितियों में जहां स्वामित्व को स्थानांतरित करने की आवश्यकता होती है, इसे छिपे हुए तरीके से नहीं किया जाना चाहिए। इससे आमतौर पर प्रोग्रामर को auto_ptr के साथ उपयोग किए जाने वाले कोड के लिए अतिरिक्त सावधानी बरतने की आवश्यकता होती है, अन्यथा खाली पॉइंटर के लिए एक्सेस हो सकता है। auto_ptr के उपयोग के दो सामान्य स्थल हैं, एक तो यह है कि इसे auto_ptr उत्पन्न करने वाले फ़ंक्शन के बाहर बुद्धिमान पॉइंटर के रूप में पास किया जाता है, और दूसरा यह है कि auto_ptr को RAII मैनेजमेंट क्लास के रूप में उपयोग किया जाता है, जिससे ऑटो पॉइंटर के जीवनकाल के बाहर जाने पर संसाधन स्वचालित रूप से मुक्त हो जाता है। पहले स्थल के लिए, इसके बजाय std::shared_ptr का उपयोग किया जा सकता है। दूसरे स्थल के लिए, C++11 स्टैंडर्ड में std::unique_ptr का उपयोग किया जा सकता है। जहां std::unique_ptr std::auto_ptr का विकल्प है, जो स्पष्ट स्वामित्व स्थानांतरण का समर्थन करता है।

अपवाद: C++11 स्टैंडर्ड के व्यापक उपयोग से पहले, जहां भी स्वामित्व को स्थानांतरित करने की आवश्यकता होती है, std::auto_ptr का उपयोग किया जा सकता है, लेकिन std::auto_ptr को लपेटने और लपेटने वाले वर्ग के कॉपी कंस्ट्रक्टर और असाइनमेंट ऑपरेटर को अक्षम करने की अनुशंसा की जाती है, ताकि उस लपेटने वाले वर्ग का उपयोग मानक कंटेनर में नहीं किया जा सके।

सुझाव 9.5.2 नए स्टैंडर्ड हेडर फ़ाइल का उपयोग करें

स्पष्टीकरण: C++ के स्टैंडर्ड हेडर फ़ाइल का उपयोग करते समय, <cstdlib> जैसे का उपयोग करें, न कि <stdlib.h> जैसे।

const का उपयोग

चर या पैरामीटर के लिए const कीवर्ड का उपयोग करके const int foo जैसे चर के मान को बदले जाने से बचाया जा सकता है। क्लास में फ़ंक्शन के लिए const क्वालीफ़ायर जोड़कर यह दर्शाया जा सकता है कि फ़ंक्शन क्लास मेम्बर वेरिएबल की स्थिति को संशोधित नहीं करेगा (जैसे class Foo { int Bar(char c) const; };)। const चर, डेटा मेम्बर, फ़ंक्शन और पैरामीटर कंपाइल-टाइम प्रकार जांच में एक सुरक्षा परत जोड़ते हैं, जिससे जल्दी त्रुटि पता चल सकती है। इसलिए, हम अधिकतम संभवतः const का उपयोग करने की सलाह देते हैं। कभी-कभी, C++11 के constexpr का उपयोग वास्तविक स्थिरांक को परिभाषित करने के लिए बेहतर हो सकता है।

नियम 9.6.1 पॉइंटर और रेफ़रेंस प्रकार के फॉर्मल पैरामीटर के लिए, यदि आपको इसे संशोधित नहीं करना है, तो const का उपयोग करें

अपरिवर्तित मूल्य को समझने/ट्रैक करने और विश्लेषण करने में आसानी होती है, const को डिफ़ॉल्ट विकल्प के रूप में रखें, इसे संकलित समय पर जांचा जा सकता है, जिससे कोड अधिक मजबूत/सुरक्षित होता है।

class Foo;

void PrintFoo(const Foo& foo);

नियम 9.6.2 सदस्य चर को संशोधित न करने वाले सदस्य फ़ंक्शन के लिए const मॉडिफ़ायर का उपयोग करें

संभवतः सभी सदस्य फ़ंक्शन को const के रूप में घोषित करें। एक्सेस फ़ंक्शन हमेशा const होना चाहिए। डेटा मेम्बर को संशोधित न करने वाले सभी सदस्य फ़ंक्शन को const के रूप में घोषित किया जाना चाहिए। वर्चुअल फ़ंक्शन के लिए, इसे डिज़ाइन इंटेंट पर विचार करना चाहिए कि क्या विरासत श्रृंखला में विरासत में मिले सभी वर्गों को इस वर्चुअल फ़ंक्शन में डेटा मेम्बर संशोधित करने की आवश्यकता है, न कि केवल एकल वर्ग के अमल पर विचार करना चाहिए।

class Foo {
public:

    // ...

    int PrintValue() const // const सदस्य फ़ंक्शन को संशोधित करता है, सदस्य चर को संशोधित नहीं करता है
    {
        std::cout << value_ << std::endl;
    }

    int GetValue() const  // const सदस्य फ़ंक्शन को संशोधित करता है, सदस्य चर को संशोधित नहीं करता है
    {
        return value_;
    }

private:
    int value_;
};

सुझाव 9.6.1 प्रारंभिककरण के बाद संशोधित नहीं होने वाले सदस्य चर को const के रूप में परिभाषित करें

class Foo {
public:
    Foo(int length) : dataLength_(length) {}
private:
    const int dataLength_; 
};

अपवाद

सुझाव 9.7.1 C++11 में, यदि फ़ंक्शन अपवाद फेंकता नहीं है, तो इसे noexcept के रूप में घोषित करें

कारण

1. यदि फ़ंक्शन अपवाद फेंकता नहीं है, तो इसे noexcept के रूप में घोषित करने से कंपाइलर फ़ंक्शन को अधिकतम रूप से अनुकूलित कर सकता है, जैसे कि निष्पादन पथ को कम करना, त्रुटि बाहर निकलने की दक्षता बढ़ाना।
2. vector जैसे STL कंटेनर, इंटरफ़ेस के मजबूती को सुनिश्चित करने के लिए, यदि तत्वों को संग्रहीत करने वाले move ऑपरेटर को noexcept के रूप में घोषित नहीं किया गया है, तो कंटेनर के विस्तार में तत्वों को ले जाते समय यह move तंत्र का उपयोग नहीं करेगा, बल्कि copy तंत्र का उपयोग करेगा, जिससे प्रदर्शन में कमी का जोखिम होगा। यदि कोई फ़ंक्शन अपवाद नहीं फेंकता है, या एक प्रोग्राम ने किसी फ़ंक्शन द्वारा फेंके गए अपवाद को पकड़ने और प्रोसेस करने की इच्छा नहीं रखता है, तो इस फ़ंक्शन को नए noexcept कीवर्ड के साथ सजाया जा सकता है, जिसका अर्थ है कि यह फ़ंक्शन अपवाद नहीं फेंकेगा या फेंके गए अपवाद को पकड़ा नहीं जाएगा और प्रोसेस नहीं किया जाएगा। उदाहरण के लिए:

extern "C" double sqrt(double) noexcept;  // अपवाद नहीं फेंकता है

// यहां तक कि अपवाद फेंक सकता है, noexcept का उपयोग किया जा सकता है
// यहां मेमोरी समाप्त होने के अपवाद को प्रोसेस नहीं किया जा रहा है, इसलिए सरलता से फ़ंक्शन को noexcept के रूप में घोषित किया गया है
std::vector<int> MyComputation(const std::vector<int>& v) noexcept
{
    std::vector<int> res = v;    // अपवाद फेंक सकता है
    // कुछ काम करें
    return res;
}

उदाहरण

RetType Function(Type params) noexcept;   // अधिकतम अनुकूलित
RetType Function(Type params);            // कम अनुकूलित

// std::vector के move ऑपरेशन में noexcept की घोषणा करने की आवश्यकता होती है
class Foo1 {
public:
    Foo1(Foo1&& other);  // no noexcept
};

std::vector<Foo1> a1;
a1.push_back(Foo1());
a1.push_back(Foo1());  // कंटेनर विस्तार को ट्रिगर करता है, जब तत्वों को ले जाया जाता है तो copy constructor को कॉल किया जाता है

class Foo2 {
public:
    Foo2(Foo2&& other) noexcept;
};

std::vector<Foo2> a2;
a2.push_back(Foo2());
a2.push_back(Foo2());  // कंटेनर विस्तार को ट्रिगर करता है, जब तत्वों को ले जाया जाता है तो move constructor को कॉल किया जाता है

ध्यान दें डिफ़ॉल्ट कंस्ट्रक्टर, डिस्ट्रक्टर, swap फ़ंक्शन, move ऑपरेटर अपवाद नहीं फेंकना चाहिए।

टेम्पलेट और जेनेरिक प्रोग्रामिंग

नियम 9.8.1 OpenHarmony प्रोजेक्ट में जेनेरिक प्रोग्रामिंग का उपयोग निषिद्ध है

जेनेरिक प्रोग्रामिंग और ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के विचार, विचारधारा और तकनीकें पूरी तरह से अलग हैं, OpenHarmony प्रोजेक्ट मुख्यधारा ऑब्जेक्ट-ओरिएंटेड विचार का उपयोग करता है।

C++ जेनेरिक प्रोग्रामिंग के लिए शक्तिशाली तंत्र प्रदान करता है, जो प्रकार-सुरक्षित इंटरफ़ेस को लागू करने में सक्षम है जो कोड की पुनः उपयोग को प्रकार अलग है लेकिन व्यवहार समान को सक्षम करता है।

लेकिन C++ जेनेरिक प्रोग्रामिंग में निम्नलिखित कमियां हैं:

1. जेनेरिक प्रोग्रामिंग में बहुत अधिक कुशल नहीं होने वाले लोग, अक्सर ऑब्जेक्ट-ओरिएंटेड लॉजिक को टेम्पलेट में लिखते हैं, टेम्पलेट में टेम्पलेट पैरामीटर पर निर्भर नहीं होने वाले सदस्यों को लिखते हैं आदि जिससे तर्क भ्रम, कोड फैलाव आदि कई समस्या होती हैं।
2. टेम्पलेट प्रोग्रामिंग के लिए उपयोग की जाने वाली तकनीकें C++ में बहुत अधिक कुशल नहीं होने वाले लोगों के लिए अधिक अस्पष्ट हैं। जटिल स्थान में टेम्पलेट का उपयोग करने वाले कोड को पढ़ना और बनाए रखना और डीबग करना भी मुश्किल होता है।
3. टेम्पलेट प्रोग्रामिंग अक्सर कंपाइल त्रुटि संदेशों को बहुत अस्पष्ट बना देता है: कोड में त्रुटि होने पर, भले ही इंटरफ़ेस बहुत सरल हो, टेम्पलेट के आंतरिक कार्यान्वयन का विवरण त्रुटि संदेश में प्रदर्शित होता है। जिससे त्रुटि संदेश को पढ़ना और समझना बहुत मुश्किल होता है।
4. टेम्पलेट का उपयोग गलत तरीके से किया जाने पर, रनटाइम कोड में अत्यधिक फैलाव हो सकता है।
5. टेम्पलेट कोड को संशोधित और पुनर्गठित करना मुश्किल होता है। टेम्पलेट कोड कई संदर्भ में विस्तारित होता है, इसलिए यह पुष्टि करना मुश्किल होता है कि पुनर्गठन सभी विस्तारित कोड के लिए उपयोगी है।

इसलिए, OpenHarmony के अधिकांश घटक टेम्पलेट प्रोग्रामिंग को निषिद्ध करते हैं, केवल कुछ घटक जेनेरिक प्रोग्रामिंग का उपयोग कर सकते हैं, और विकसित टेम्पलेट में विस्तृत टिप्पणी होनी चाहिए। अपवाद:

1. stl अनुकूलन परत टेम्पलेट का उपयोग कर सकती है

मैक्रो

C++ भाषा में, हम जितना संभव हो उतना जटिल मैक्रो का उपयोग करने से बचने की सलाह देते हैं

• स्थिरांक परिभाषा के लिए, पिछले अध्याय में बताए गए अनुसार const या एन्यूमरेशन का उपयोग करें;
• मैक्रो फ़ंक्शन के लिए, यथासंभव सरल होना चाहिए, और नीचे दिए गए सिद्धांतों का पालन करना चाहिए, और इनलाइन फ़ंक्शन, टेम्पलेट फ़ंक्शन आदि के बजाय उपयोग करने की प्राथमिकता देनी चाहिए।

// मैक्रो फ़ंक्शन का उपयोग करना अनुशंसित नहीं है
#define SQUARE(a, b) ((a) * (b))

// कृपया टेम्पलेट फ़ंक्शन, इनलाइन फ़ंक्शन आदि का उपयोग करें।
template<typename T> T Square(T a, T b) { return a * b; }

यदि मैक्रो का उपयोग करने की आवश्यकता है, तो C भाषा नियम के संबंधित अध्याय को देखें। अपवाद: कुछ सामान्य और परिपक्व अनुप्रयोग, जैसे कि new, delete के लिए मैक्रो के माध्यम से एन्कैप्सूलेशन हैंडलिंग, मैक्रो के उपयोग को बनाए रख सकते हैं।

10 आधुनिक C++ विशेषताएं

ISO द्वारा 2011 में C++11 भाषा मानक जारी करने और 2017 में C++17 को मार्च में जारी करने के साथ, आधुनिक C++ (C++11/14/17 आदि) में प्रोग्रामिंग दक्षता, कोड गुणवत्ता में सुधार के लिए बहुत सारे नए भाषा विशेषता और स्टैंडर्ड लाइब्रेरी को जोड़ा गया है। इस अध्याय में कुछ निर्देशन शामिल हैं जो टीम को आधुनिक C++ का अधिक कुशलता से उपयोग करने में मदद कर सकते हैं, भाषा जाल से बच सकते हैं।

कोड संक्षिप्तता और सुरक्षा में सुधार

सुझाव 10.1.1 auto का उपयोग उचित ढंग से करें

कारण

• auto लंबे, दोहराए गए प्रकार नाम लिखने से बचा सकता है, और इनिशियलाइज़ेशन के साथ चर परिभाषित करने में मदद कर सकता है।
• auto प्रकार निष्कर्षण नियम जटिल है, जिसे ध्यान से समझने की आवश्यकता है।
• यदि यह कोड को अधिक स्पष्ट बना सकता है, तो स्पष्ट प्रकार का उपयोग जारी रखें, और केवल स्थानीय चर में auto का उपयोग करें।

उदाहरण

// लंबे प्रकार नाम से बचें
std::map<string, int>::iterator iter = m.find(val);
auto iter = m.find(val);

// दोहराए गए प्रकार नाम से बचें
class Foo {...};
Foo* p = new Foo;
auto p = new Foo;

// इनिशियलाइज़ेशन सुनिश्चित करें
int x;    // संकलित होता है, इनिशियलाइज़ेशन नहीं होता है
auto x;   // संकलन विफल होता है, इनिशियलाइज़ेशन की आवश्यकता होती है

auto प्रकार निष्कर्षण से भ्रम पैदा हो सकता है:

auto a = 3;           // int
const auto ca = a;    // const int
const auto& ra = a;   // const int&
auto aa = ca;         // int, const और reference को नज़रअंदाज़ करता है
auto ila1 = { 10 };   // std::initializer_list<int>
auto ila2{ 10 };      // std::initializer_list<int>

auto&& ura1 = x;      // int&
auto&& ura2 = ca;     // const int&
auto&& ura3 = 10;     // int&&

const int b[10];
auto arr1 = b;        // const int*
auto& arr2 = b;       // const int(&)[10]

auto प्रकार निष्कर्षण में reference को नज़रअंदाज़ करने के बारे में ध्यान न रखने पर, यह एक महत्वपूर्ण प्रदर्शन समस्या का कारण बन सकता है:

std::vector<std::string> v;
auto s1 = v[0];  // auto को std::string के रूप में निष्कर्षित किया गया, v[0] की प्रतिलिपि बनाई गई

यदि आप auto का उपयोग इंटरफ़ेस में करते हैं, जैसे कि हेडर फ़ाइल में स्थिरांक, तो विकासकर्ता द्वारा मान में संशोधन करने पर प्रकार परिवर्तन का कारण बन सकता है।

नियम 10.1.1 वर्चुअल फ़ंक्शन को ओवरराइट करते समय override या final कीवर्ड का उपयोग करें

कारण override और final कीवर्ड यह सुनिश्चित करते हैं कि फ़ंक्शन एक वर्चुअल फ़ंक्शन है, और बेस क्लास के वर्चुअल फ़ंक्शन को ओवरराइट करता है। यदि सब क्लास फ़ंक्शन बेस क्लास फ़ंक्शन प्रोटोटाइप से मेल नहीं खाता है, तो संकलन चेतावनी उत्पन्न होती है। final यह भी सुनिश्चित करता है कि वर्चुअल फ़ंक्शन को सब क्लास द्वारा ओवरराइट नहीं किया जा सकता है।

override या final कीवर्ड का उपयोग करने के बाद, यदि बेस क्लास वर्चुअल फ़ंक्शन प्रोटोटाइप को संशोधित किया जाता है, लेकिन सब क्लास में ओवरराइट वर्चुअल फ़ंक्शन को संशोधित करने के बारे में भूल जाते हैं, तो संकलन समय में इसे पता लगाया जा सकता है। यह कई सब क्लास होने पर वर्चुअल फ़ंक्शन ओवरराइट संशोधन के लिए उपयोग किया जा सकता है।

उदाहरण

class Base {
public:
    virtual void Foo();
    virtual void Foo(int var);
    void Bar();
};

class Derived : public Base {
public:
    void Foo() const override; // संकलन विफल: Derived::Foo और Base::Foo प्रोटोटाइप मेल नहीं खाते, ओवरराइट नहीं है
    void Foo() override;       // सही: Derived::Foo Base::Foo को ओवरराइट करता है
    void Foo(int var) final;   // सही: Derived::Foo(int) Base::Foo(int) को ओवरराइट करता है, और Derived का डेरिवेटिव क्लास इस फ़ंक्शन को ओवरराइट नहीं कर सकता
    void Bar() override;       // संकलन विफल: Base::Bar वर्चुअल फ़ंक्शन नहीं है
};

सारांश

1. बेस क्लास में पहली बार वर्चुअल फ़ंक्शन परिभाषित करें, virtual कीवर्ड का उपयोग करें
2. सब क्लास में बेस क्लास वर्चुअल फ़ंक्शन (डिस्ट्रक्टर सहित) को ओवरराइट करें, override या final कीवर्ड का उपयोग करें (लेकिन दोनों का एक साथ उपयोग न करें), और virtual कीवर्ड का उपयोग न करें
3. गैर-वर्चुअल फ़ंक्शन, virtual, override और final का उपयोग न करें

नियम 10.1.2 delete कीवर्ड का उपयोग फ़ंक्शन को हटाने के लिए करें

कारण private में घोषित किए गए लेकिन लागू नहीं किए गए क्लास मेम्बर फ़ंक्शन की तुलना में delete कीवर्ड अधिक स्पष्ट है, और अधिक व्यापक रूप से उपयोग किया जा सकता है।

उदाहरण

class Foo {
private:
    // हेडर फ़ाइल को देखकर यह नहीं पता चलता कि कॉपी कंस्ट्रक्टर हटा दिया गया है
    Foo(const Foo&);
};

class Foo {
public:
    // स्पष्ट रूप से कॉपी असाइनमेंट फ़ंक्शन को हटा दिया गया है
    Foo& operator=(const Foo&) = delete;
};

delete कीवर्ड गैर-मेम्बर फ़ंक्शन को हटाने के लिए भी समर्थित है

template<typename T>
void Process(T value);

template<>
void Process<void>(void) = delete;

नियम 10.1.3 NULL या 0 के बजाय nullptr का उपयोग करें

कारण लंबे समय तक, C++ के पास एक खाली पॉइंटर कीवर्ड नहीं था, जो एक असहज स्थिति थी:

#define NULL ((void *)0)

char* str = NULL;   // गलत: void* को char* में स्वचालित रूप से कनवर्ट नहीं किया जा सकता है

void(C::*pmf)() = &C::Func;
if (pmf == NULL) {} // गलत: void* को मेम्बर फ़ंक्शन पॉइंटर में स्वचालित रूप से कनवर्ट नहीं किया जा सकता है

यदि NULL को 0 या 0L के रूप में परिभाषित किया गया है। उपरोक्त समस्या का समाधान किया जा सकता है।

या खाली पॉइंटर के लिए सीधे 0 का उपयोग किया जा सकता है। लेकिन इससे एक और समस्या होती है, कोड स्पष्ट नहीं होता है, विशेष रूप से auto के स्वचालित निष्कर्षण का उपयोग करते समय:

auto result = Find(id);
if (result == 0) {  // Find() क्या पॉइंटर या पूर्णांक लौटाता है?
    // कुछ काम करें
}

0 शाब्दिक रूप से int प्रकार है (0L है long), इसलिए NULL और 0 दोनों पॉइंटर प्रकार नहीं हैं। जब पॉइंटर और पूर्णांक प्रकार के फ़ंक्शन को ओवरलोड किया जाता है, तो NULL या 0 को पास करने से पूर्णांक प्रकार ओवरलोड फ़ंक्शन को कॉल किया जाता है:

void F(int);
void F(int*);

F(0);      // F(int) को कॉल किया जाता है, F(int*) नहीं
F(NULL);   // F(int) को कॉल किया जाता है, F(int*) नहीं