qq_35152332的博客

源网址：CppCoreGuidelines原因使用设计良好、文档齐全且支持良好的库可以节省时间和精力；如果你必须将大部分时间花在实现上，那么它的质量和文档可能会比你所能做的更好。库的成本（时间、精力、金钱等）可以由许多用户分担。与单个应用程序相比，广泛使用的库更有可能保持时效性和新系统可移植性。了解广泛使用的库可以节省其他/未来项目的时间。因此，如果的的应用程序领域存在合适的库，请使用它。例子std::sort(begin(v), end(v), std::greater<>());

源网址：CppCoreGuidelines原因很多事情“通过机器”可以做的更好。计算机不会对重复的工作感到疲惫或者无聊。我们通常有更好的东西去重复做常规工作。例子运行静态分析工具取验证你的代码遵守你希望的准则。注意参考（PS：这里工具没有链接，可能还没有添加上）静态分析工具并发工具测试工具还有许多其他类型的工具，例如源代码存储库、构建工具等，但这些超出了这些指南的范围。注意小心不要依赖过度精心设计或过度专业化的工具链。这些可以使你的代码不可移植。...

源网址：CppCoreGuidelines原因混乱代码更难开发且容易隐藏bug。一个好的接口应该能够简单安全的使用。混乱低级的代码会导致更多这样的代码。例子int sz = 100;int* p = (int*) malloc(sizeof(int) * sz);int count = 0;// ...for (;;) { // ... read an int into x, exit loop if end of file is reached ... // ... che

源网址：CppCoreGuidelines原因推理常量比变量更简单。常量不可能发生不可预期的改变。常量可以进行更好的优化。你不能在常量上进行数据争夺。参考常量篇：常量和不变性

原因因为这是C++!注意为了实现目标（例如开发速度，资源安全或者简化测试）花费的时间和空间不算浪费。“追求效率的另一个好处是，这个过程会迫使你更深入地理解问题。” -Alex Stepanov（PS：STL之父）反例struct X { char ch; int i; string s; char ch2; X& operator=(const X& a); X(const X&);};X waste(const ch

原因随着时间推移，即使缓慢的资源增长也会耗尽可用资源。这对长时间运行的程序尤其重要，而且是负责任的编程行为很重要的一部分。反例void f(char* name){ FILE* input = fopen(name, "r"); // ... if (something) return; // bad: if something == true, a file handle is leaked // ... fclose(input);}最好使用RA

原因避免“神秘的”崩溃，避免错误导致（可能无法识别的）错误结果。例子void increment1(int* p, int n) // bad: error-prone{ for (int i = 0; i < n; ++i) ++p[i];}void use1(int m){ const int n = 10; int a[n] = {}; // ... increment1(a, m); // maybe typo, maybe m

源网址：CppCoreGuidelines原因在程序中留下难以检测的错误会导致崩溃和错误结果。注意理想情况下，我们在编译期和运行期捕获程序的所有错误（除了程序的逻辑错误）。在编译期捕获所有错误是不可能的，但是运行期捕获所有遗留的错误通常是难以承受的。但是在资源充足的条件下（分析程序、运行时检查、机器资源、时间），我们应该努力编写原则上可以检查的程序。反例// separately compiled, possibly dynamically loadedextern void f(int* p

源网址：CppCoreGuidelines原因代码清晰和高效。你不需要对编译期捕获的错误写异常处理。例子// Int is an alias used for integersint bits = 0; // don't: avoidable codefor (Int i = 1; i; i <<= 1) ++bits;if (bits < 32) cerr << "Int too small\n";这个例子不能实现它想要的功能

源网址：CppCoreGuidelines原因理想情况下，一个程序应当是完全静态（编译期）类型安全的。不幸的是，这不可能，问题区：联合体类型转化数组退化范围错误缩小（截断）转换注意这些区域是一系列问题之源（例如崩溃和安全违规）。我们尝试提供替换技术。补充我们可以根据个别程序的需要和可行性，单独禁止、限制或者检测个别问题。通常的建议是替换，例如：联合体：使用variant（c++17）转换：尽可能不使用，用模板数组退化：使用span（来自GSL）范围错误：使用span缩小

源网址：CppCoreGuidelines原因除非表明了代码的意图（通过命名和注释），否则很有必要告知代码是否做了它计划做的事例子gsl::index i = 0;while (i < v.size()) { // ... do something with v[i] ...}这里没有表达只是循环v中元素的意图。下标的执行细节是暴露的（所以可能被误用），而且i的生命周期超过了循环作用域，这可能是也可能不是本意，读者不能从这段代码中推断出来。更好的表达：for (const

源网址：CppCoreGuidelines原因这是一组编写ISO标准C++的准则。注意有些环境使用拓展是必需的，例如访问系统资源。在这种场景下，定位必要拓展并且按照非核心准则控制他们的使用。可能的话，构建接口将这些拓展封装，以便在不支持这些拓展的系统上不编译或者关闭掉。拓展通常没有严格定义语义。甚至因为没有严格的标准定义，通用的拓展在不同的编译环境下可能有轻微的不同行为和边界条件处理。注意使用有效的ISO C++并不能保证可移植性（更别说准确性）。避免依赖于未定义的行为（例如未定义的求值顺序）

源网址：CppCoreGuidelines简介（我自己写的，其他是翻译的）c++核心准则是C++之父Bjarne Stroustrup针对现代C++(C++11\14\17)开发制定的一套，旨在提高程序质量的实时更新准则，在github社区维护。这套准则针对代码安全性、可读性、兼容性、并发及效率等提出了一系列启发性的建议和可行的改进措施。我认为是提升代码质量的一套非常有价值的建议，希望可以坚持翻译下去。原因编译器和大多数程序员不会阅读注释和设计文档，但是在代码中表达的语义可以通过编译器和其他工具检查

C++ for循环效率优化背景今天看到同事的代码，commit message说要提高循环效率，但是看起来非常浪费时间，我就想试一下for循环怎么写运行最快，发现还是非常有意思的。首先是编译选项，在X86系统编译Release，优化等级-O3，关闭gdbSET(CMAKE_BUILD_TYPE "Release")SET(CMAKE_CXX_FLAGS_RELEASE "$ENV{CXXFLAGS} -O3 -Wall") 这个循环非常简单，遍历一个结构体的vector，读一下数据执行一些操作

最近要公司开发一个机器人分布式调度器，刚刚毕业的我瑟瑟发抖，准备用单例模式向机器人提供调度算法接口，赶紧补习下知识。什么是单例模式单例模式是一种常用的设计模式，主要指在程序运行过程中，一个类有且仅有一个实例，并且向外提供获取该实例的接口。实现单例模式有三个要点：类只能有一个实例；类自行创建这个实例；类自行向整个系统提供这个实例。简单的懒汉式实现最简单的懒汉式实现单例模式：class Singleton{private: Singleton() { std::cout <<