ColdWindHA的博客

用作变量类型推演的关键字auto可能是C++11最著名的特性了，所以这篇文章我长话短说，简单写一下我认为比较重要的使用法则。怎么用 auto这一节我会写得尽可能短，因为我默认大家都已经用过auto了。如果有谁没用过的话，有大量的书和文章来替我讲这方面的知识。我们都是用auto这个关键字来代替一个具体变量的类型定义，让编译器自己去寻找和从它的初始化过程中来推演这个变量的类型。最著名的关于auto的用法恐怕莫过于用它来躲开一堆长长的类型名，比如STL容器的iterator，但是它也可以有其他用处：std

C++ 顶层 const 和底层 const从 const 指针开始说起。const int* pInt; 和 int *const pInt = &someInt;，前者是 *pInt 不能改变，而后者是 pInt 不能改变。因此指针本身是不是常量和指针所指向的对象是不是常量就是两个互相独立的问题。用顶层表示指针本身是个常量，底层表示指针所指向的对象是个常量。更一般的，顶层 const 可以表示任意的对象是常量，这一点对任何数据类型都适用；底层 const 则与指针和引用等复合类型有关，比较特

强枚举到底有多“强”传统枚举类型以及其特性在开发上的弊端已逐渐显露，C++11标准对原有枚举类型进行了加强和补充，从而衍生出了"强枚举"。本文不仅旨在讲清楚强枚举是如何在弱枚举上进行改进，更希望阐明弱枚举的种种不足是如何对开发造成不利影响的；以及同时C++11"新标准"（早已不新）是如何对98的枚举进行补充的。枚举无处不在在工程代码当中，只要和数据打交道，基本上就离不开枚举类型——这是因为单纯的字符串类型在一份合格的工程代码中是不应该出现的，所有的字符串都应以枚举或常量的形式定义。举个例子，如果我们有

引子——左值持久；右值短暂在C++11以前，所有引用都是左值引用(lvalue reference)——对左值的引用。lvalue这个词来自于C语言，指的是可以放在赋值表达式左边的对象，这些对象都是在对上或栈上分配的命名对象，他们有明确的内存地址。相对应的右值rvalue，如文字常量和临时变量，指的是可以出现在赋值表达式右侧的对象。左值引用只能绑定在左值上，右值就会编译错误：int& i = 419; // Compile Error好吧，这个错误有点蠢，应该也不会有人会这样用。但是我们通常

从一个惨案说起在一个项目中，我们开发的同学需要调用算法同学提供的一个接口，这个函数除了所有必要的参数之外，最后还有一个“多余的“参数void*类型，即一个可以指向任何类型的指针。这个参数之所以存在，是因为这个接口是一个算法过程的入口，在算法的最后会自动调用一个回调函数callBack，回调函数是我们自己定义的，可以用来回收所传进去的void*参数所开辟的内存，整个过程实现了算法和主流程的异步处理。其中算法可抽象成：void func_with_void_pointer(int par1, char pa

你是否在混着用NULL和nullptr？你是否分不清这二者到底有什么区别？滥用NULL到底会带来什么不可思议的错误？今天，我们就来讨论讨论nullptr这个空指针的救世主。在C++11之前，几乎所有人写代码时对NULL又爱又恨，爱是因为他确实能够起到空指针的作用，恨是刚躲过了这个坑，又遇见了那个妖，魑魅魍魉怎么它就这么多。还好，C++11给我们带来了希望的曙光——nulltpr。什么是NULL？这个问题想要回答好还真是不容易。从定义上来看，NULL是一个宏，它被定义为0（也就是int型的零），或者

C++ 17 在 STL 中加入了许多新的"vocabulary types"，这些类型时用在不同组件的接口处的。MSCV也在Visual Studio2017中添加了对诸如std::optional,std::any和std::variant的支持。在这篇文章中，我们就来看一下std::optional解决了哪些问题，以及如何正确使用它。表达“有时存在”在程序中，有时我们需要变量来表达“nothing”的意思，比如你怎么写一个函数来“有可能“返回一个值？就好像给我找出一段文字中的第一个偶数，如果有的话

今天我想谈谈override和final，这一对在C++11中不太引人注意的特性，相比于C++11其他特性而言也更简单。这两个特性都能让我们的程序在继承类和覆写虚函数时更安全，更清晰。覆写（override）虚函数你有没有像我一样遇到过这种情况：在子类中，本来你想覆写虚函数，结果虚函数却没有被正确地调用呢？或者更惨的是，你有时不得不去修改父类虚函数的声明。在所有的子类中查找重载的函数这件事可真的是很麻烦，而且墨菲定律告诉你：你永远会忘掉你搞错了的那一个子类。不管怎么样，看下边这个例子吧： struct

使用constexpr进行编译期运算在上面两篇文章我分别介绍了什么是编译期常量以及C++03标准中的编译期运算。这篇文章我将围绕在constexpr这个关键字展开。C++03中编译期运算的限制我在上篇文章中所举的例子，要么非常简单，要么就是和模板元编程有关。非模板元编程的方法往往是一行就结束了，难以实现复杂的运算。此外我们还不能复用代码，无论在哪里我们都要再复制粘贴一遍，不符合我们设计代码的准则。模板元编程往往又非常的复杂，可读性也不高，虽然在C++14标准中我们有了可变参数模板，它能适当地改善模板元

C++11标准前的编译期运算在第一篇文章中，我把主要精力放在了什么是编译期常量，以及编译期常量有什么作用上。在这一篇文章中，我将更详细地介绍编译期常量是如何产生的。之所以要把编译期常量了解的这么透彻，是因为他是编译期运算的基础。在这篇文章中还会讲解我们在C++11 标准前都可以用做哪些**编译期运算（**compile-time calculations），通过了解这些比较原始的方法，我们能够更好地理解C++11标准为编译期运算方面所做的工作。编译期常量都从哪里来？在我们的经验中，大部分编译期常量的来

从编译期常量谈起C++20都支持虚函数的constexpr了，我打算用三篇读文章讲清楚编译期常量和constexpr这个东西和编译期常量的关系，即为什么需要他来辅助解决这个问题。最后帮助读者在实际编码过程中能够有意识地去运用他们，这才是终极目标。这篇文章中会讲到隐藏在日常编程中的各种编译期常量，以及他们存在的意义。什么是编译期常量想要用编译期常量就要首先知道它们是什么，一般出现在哪里和运行期常量有什么区别，因此我打算用第一篇文章重点分析编译期常量以及使用他们有什么好处。编译期常量(Compile-t