fpcc的专栏

一定要明白状态机的目的和作用，要学会在不同的场景和条件灵活的使用状态机。一般情况下，状态机的设计不要过于复杂，这样不利用状态机的维护。同样过于简单的情况也不一定非得要用状态机。至于如何避免复杂，就记住一句话，拆分状态逻辑，利用中间层处理。状态机和其实现的方式，其实都是重点，重点在于如何将状态机与实际的实现逻辑严格的对应起来，保证状态的稳定和准确，特别是不能忽视某些特定条件的状态转换及行为的细微差异。只要能把握完整的状态流程，状态机的实现也就是一种代码的展开罢了。

技术的进步不是一朝一夕完成的，它一定是从需求出发，不断的进行完善，然后被抽象出来。无论是RVO还是各种的内存优化，当然也包括今天提到的就地构造等，它们都是对追求效率和安全的一种演进过程。不管是开发者还是设计者，都要多学习这种优秀的经验，不断的融会贯通，提高自己的整体的水平。既要拿来主义，又要明白主义，博采众家之长，这才是学习的最终目的。

std::not_fn这个模板函数非常有意思，在前面我们学习过wrapper（包装器），其实它就是通过封装一个包装器来实现返回值的非。/* 未指定 */ not_fn( F&& f );(1) (C++17 起)(C++20 起为 constexpr)constexpr /* 未指定 */ not_fn() noexcept;(2) (C++26 起)这里面的f参数是一个Callable对象。

老生常谈，其实就是一个原则。在合适的场景下应用合适的方法，不教条不僵化。尽量减少使用不是强制不使用，难免有各种场景下不得不用，那么就需要认真的处理即可。有隐患不是说就一定会出现，只要把握内部的机理，就不会出现问题。

文章写得有点粗糙，主要是不知道如何有一个更好的切入点来分析定时器。不过也算对前面各种定时器的实现的一个笼统的概括，以后有机会再认真的综合整理一下。思考的不到位，有一种火候欠佳的感觉！

简单方便是一种趋势。虽然有人诟病C++现在是个大缸，啥都往里面放。但不可否认，新标准在不断的提高着语言整体的易用性，这也给开发者们一个思路，也就是常说的“简约但不简单”。

AI在发展，库也在发展，会不会到最后，大家只要碎碎念一下，一个程序就出来？这种不是没有可能。但是这种可能，大概率可能需要相当长的时间。其实如果真到了那个地步，为什么还要写程序？机器人自己就搞定自己了。人类就享受一切即可。不过到那时，可能大多数人活得更不如意！

看到std::atomic_ref，其实就想到了智能指针，二者应用的方式何其相似。从目的上来讲就是为了让开发变得简单，特别是在多线程状态下的开发，能简单一些是一些。另外就是为了兼容更多的原有的应用让其都能使用std::atomic的功能。或者从另外一个角度看，std::atomic_ref只是一个过渡的功能，以后会出现一个更强大的类或接口，让原子操作更简单。让我们拭目以待！

CRTP是一种静态多态的实现方法。说的直白一些就是在正常的认知中，子类继承的是父类，但是如果父类是一个模板类，此模板类中的模板参数是子类的这种特殊情况。CRTP在前面说过两次，如果有对此技术不清楚的可以查看一下“跟我学c++中级篇——CRTP”以及“显式this的应用”中都进行过分析说明。CRTP本身就是一种很小众的技术应用，而它的一些应用，可能应用范围更小，下面就一些细节进行分析，扩展一下CRTP的更多的应用场景，给大家提供一些应用上的思路。CRTP的应用，相对来说就是一种比较复杂的应用。在前面将其基础

对大多数开发者来说，这种警惕性可以有，但并不迫切。如果真得有机会搞到底层或硬件相关，再深入的学习和分析才是正解。但仍然在开发中要保持对不同位数系统的敏感，这才能避开系统引入的各种雷区。

在实际的开发中，一般说很难固定使用哪一种初始化的方式。但总体的原则还是要把握住，以简单方便为前提，安全高效为核心，不必过分拘泥于形式。只要是能够让代码更清晰，符合编码规范，可以各种方式一起上。抓住耗子的猫才是好猫。

其实编程就是从这些小的功能一点点的把基础打好的。正如前面的容器中的insert,push_back和后来的emplace_back。STL库中为什么要有这么多的方法来处理元素的插入？把这些细节把握住就深刻明白了C++中容器组织的过程。从另外一个角度打开学习的途径。人生而有涯，而学之也无涯！

代码复用除了从设计角度看，其实也可以从重构的角度来看。重构的一个重要目的就是减少冗余代码，那么做好代码复用当然冗余就会大幅降低。所以说，一件事，如果从不同的维度和不同的应用方向来看，就会有不同的效果。这就又回到文中的“编程思想” 了，思想是什么？其实就是现实抽象的结果。

这里不是强调大量使用宏或者推广宏的应用，而是在应该用的场景下坚定的引入宏。合适的就是最好的，不能因噎废食，更不能搞绝对化。原则上仍然是不建议在开发中广泛而大量的应用宏，用就要用到刀刃上。

在谈字节序前讲个小故事，在小说《格列佛游记》中，有两派势力为了吃鸡蛋的时候儿到底是先打破大的一端还是打破小的一端展开了战争，而且这场战争持续了很久。后来，1980年，Danny Cohen在论文"On Holy Wars and a Plea for Peace"中引用了这个故事来处理一场关于数据传输时字节该以什么样的顺序进行传送的争论，所以在计算机的世界中也才有了字节序这个概念。

this是一个隐式的，默认的，自动的生成的一个指针，它通过编译器在编译行为期间进行控制而不需要开发者自己控制。可以将其理解为向开发者提供了一个可以更好的访问对象的接口。但在实际的开发中，很多开发者其实并没有很好的利用this指针。这就需要开发者们能充分认识到它的作用，发挥它的长处，形成一个好的开发习惯。

其实写代码现在更注重于团队开发，所以可维护性就提高到了一个重要的程度。善于使用各种手段增强代码的可读性和维护性，本身就是一种编程水平的进步。技术的进步，是内外兼修的。有里有表，才是个帅小伙儿。

这个小故事耽误了不到两个小时，主要是原始网络库编译成功而自己的项目不能使误导了方向。但回过头来再看，发现国外做开发的人真得想得周到。只能说自己解决问题的想法还是不够严谨，也算是一次对自己的反思吧！

语言是实现设计的手段和工具，不要太在意它们的不同。选择更合适的实现和达到最终的结果，这才是一个优秀的开发人员需要做到的。而语言中的整体的设计和开发方向其实受计算机的底层限制很大，再加上几乎所有的语言设计者都是精通计算机系统的，其处理问题的思想本质也是相通的。所以，一时的不同，不代表未来的不同；实现的不同，不代表应用的表现不同。与诸君共勉！

std::void_t更好的是在模板和元编程中应用，这也是C++的一个发展的重点。毕竟泛型编程是每个语言都不能舍弃的情怀。所以对大多数程序员来说，std::void_t这个元函数属于一种应用非常少的情况。可以先了解一下，然后再真正遇到后再认真学习。在这篇普及的文章基础上，后面将对enable_if与std::void_t以及C++20中的std::integral‌进行一次系统的分析说明。这样，会让大家能从整体到细节上对模板和元编程中的相关用法有一个清晰的认识。

要想用好宏，就得把宏的了解的相当深入。宏的本质就是一种替换技术，用得好，可以产生意想不到的效果；反之，也会有意想不到效果。不过一个总的原则是，能不用宏的情况下，尽量避免使用宏编写代码。建议所有开发者能深以为之！

老生常谈的技术，可能对于不少开发者已经耳朵都听出茧子来了。可还是要说，为什么？这就和上学一样，你觉得你会了，而且你也明白了整个过程，甚至把作业都作得很好，可考试呢？大多数人仍然是一个中上游的水平。要是明白这个现象产生的道理，就明白现在这里说的什么道理。熟能生巧，但很难产生思想！大家自己意会！

技术的进步就是朝着简化开发者的应用的方向展开的。包括现在的AI，虽然说当下AI取代程序员可能有点忽悠的成分，但未来这种是大概率的事件。至少大多数的普通程序员被AI替代是一种非常可能的情况。这个时间可能不会很长。但这并不代表程序员的消失，反而有可能会出现另外一种形式的程序员。大家拭目以待吧！

在前面的文章“c++中的Abominable Function Types”，其实对引用限定符进行了比较详细的总结。但是发现在使用模糊查询时，无法搜索到这个内容。而且恰巧最近又遇到了一些这方面的代码，所以想了下还是专门总结一篇为好。

用std::any尽量控制应用的范围，即自己开发自己用，尽量不要向外暴露。不管是为了安全还是为易用，也是便于维护，都是一个比较好的习惯。但刀握在开发者的手里，想怎么用，还是根据自己的情况来。

当然，在不同语言或者不同的语言不同的版本或标准中（比如微软就对C++标准进行了扩展，从VC2005，volatile就支持了固定的内存序，可以安全的在多线程中使用），可能对volatile的应用进行了扩展，那就需要认真的看其的手册及相关技术指南。整体上讲，在没有确切的标准指导下，不建议对volatile进行更宽泛的使用。要严格按照标准的规定来应用，一般不会出什么大的问题。

学习编程到最后会发现，以前学到的操作系统、计算机原理和编译原理等等基础的知识，都会有机的融合到一起。这才感叹，只是为了学习的方便和条理清晰，才拆分成了不同的技术体系。其实，它们是有起承转合的互相依赖互相包容的一个整体。学习时要逐渐从点到线，再从线拉开一条面。最后在面的基础上，能形成多大的立体体系，就看个人的缘法和能力了。

后发语言往往能看到借鉴语言的缺点和优点。这和学习一样，有前人的经验会进步更快。所以，从这一个小的问题，可以引申出来很广大的思考。从细节的区分到设计模式、原则和设计思想的改变。这就是老师经常说的“把薄书读厚了”。

在前面分析过了节点相关的应用和功能，也在其中分析过一些节点的数据定义情况。本文就对节点的数据定义进行一个更详细具体的分析说明，特别是对一些应用上的细节展开说明一下。知其然，然后知其所以然。节点的定义，基本都是以模板进行的。所以希望大家有一些基本的模板的知识，否则看起来还是有些麻烦的。

不同的节点有着不同的处理机制，而实际的应用场景千变万化。到达罗马的大路不止一条，何况还有小路。所以，正确的选择可能有很多，但如果寻找一条更适合当前环境的设计思路，这才是重点。最好不一定合适，合适其实从某种意义上说才是最好。

锁的底层机制就是对资源的限制性利用，在效率和安全下寻求一个平衡。无论是现实世界还是计算机世界，资源的有限性才造就了竞争，而要让资源被安全的最大化利用，就需要一种管理机制，在现实世界，就是法律和道德；在计算机世界就是锁。锁，其实就是计算机中的权力的象征！谁拥有了它，就可以自由的使用资源来工作。

其实一直对这个关键字没有注意过，虽然也会使用，但也没有什么深刻的印象。有的时候看代码发现多个参数的构造函数也应用了这个关键字，也没有发现有什么不妥。直到后来一次实际操作中，才发现其实多个参数使用它没有实际意义。虽然不至于有什么问题，但仍然是对细节的把控不到位。写这篇文章就是和诸君共勉！

其实在实际应用中，二者的应用大多是泾渭分明的。但真正的细节上的区别，还是需要认真的掌握。不然在开发具体的工程时，可能会一时疏忽导致不可预测的问题和错误。还是那句话，细节决定成败，但不能拘泥于细节。这个度，就需要开发者自己不断养成自己的判断。

纸上学来终觉浅啊，还是要亲自跑一下代码。实践和理论一起向前推进，才能更好的理解相关的程序代码和其内在的运行机制。

TBB框架有很多细节需要处理，但勿需焦虑。很多的细节其实在应用的时候儿就会自然的出现，不明白再去查阅相关的文档即可。重点是掌握好其整体的逻辑流程，抓大放小，强干弱枝。还是那句话，细节很重要，但不要限入细节不可自拔。

在开发者编写代码的过程中，很多函数需要返回值的。如果只是简单的返回一个基础类型值，即使有一些浪费，这些浪费在整体的程序运行中其实影响还是相当小的。但当开发者自定义一些数据结构或者字符串等的返回时，就有可能出现多次拷贝的现象。这样的运行成本可能就相当大了。开发者在早期的编译期环境中，可能需要一些具体的技巧来处理这些返回值，但在越来越优秀的编译器加持下，返回值优化的手段从开发者不断的向编译期转移。这和前文（跟我学C++中级篇——临时对象）分析过的临时对象有着很大的联系，可一并参考学习分析。

在节点的应用中，要注意区分单输入（输出）、多输入（输出）与广播、单播的不同。前者指只有一个输入输出的节点，后者指的是数据转发的方式。一般来说，前者控制的是节点中控制数据流的点的数量，后者指的是连接发送的策略。TBB的应用还是有很多细节可挖的，可惜一般的地方用不到这个框架。有兴趣的可以一起学习分析。

TBB中图的使用是一个非常巧妙的设计，但是一定要明白图设计中的一些细节，特别是图连接状态与节点激活间先后以及是否保证数据的安全流动（如不丢失数据）。在前面分析的文章中就遇到了这类问题，所以一定要把TBB整体的流程和协调方式以及各种相关关系理清，才可能更大限度的发挥TBB的性能。

在前面的文章“C++20中的分支预测”中，对C++20中的静态分支预测进行了分析说明。本文从整体上对分支预测（Branch Prediction）进行一个全面的分析说明。首先来看一个分支预测的定义：由CPU预判程序分支的执行指令，从而减少错误方向的选择，加快运算速度。这项技术是从P5（奔腾5）处理器开始应用的。分支预测可以分为动态分支预测和静态分支预测两种。静态分支预测其实就是在编译程序时直接预测分支跳转的方向；而动态分支预测就是在程序运行时根据一定的算法来预测分支跳转方向。

仍然是那句老话，“没有包打天下的技术”。想要灵活机变的综合应用各种技术解决实际问题，首先应该把基础打好，然后在实践中不断的应用总结。要善于发扬每种技术的长处，共同配合完成工作需要。所以搞技术学一些系统工程的知识也是相当有用处的。