读《恶意的构图：侦探的委托人》 峰岸谅一被怀疑通过纵火杀害了他的岳父，因为在峰岸老人被烧死在自己公寓的晚上，谅一告知警察他未出现在公寓附近，但是邻居却作证，当天晚上看到谅一出现在公寓附近。并且警察在纵火现场发现了他的打火机，而且谅一右脸刚好有烧伤的痕迹，虽然他狡辩说自己不小心在烧开水时烫伤。另外谅一的公司出现资金周转困难，急需用钱，而峰岸老人早期通过炒股早已实现财富自由。这些线索都让警察认定他就是凶手，并且检察机关对他提起诉讼。谅一希望通过衣田律师进行辩护，奇怪的是衣田律师此前并没有进行过刑事案件的辩护。当然衣田律师接到这个案子后也尽心尽力帮助谅一进行辩护。但是对于案件的关键部分，他总是含糊其辞，辩护律师衣田征夫也被弄得晕头转向。好巧不巧，在谅一即将迎来最终判决时，谅一的妻子，朱实女士被发现不幸溺亡在别墅的地下室中。警方通过排查认定是之前被害的峰岸老人为了天冷时水管不被冻住打开了水龙头，并且一时疏忽忘记关闭水龙头，而朱实女生在不知情的情况下贸然乘坐电梯前往地下室，当电梯门开后地下室的水涌入电梯导致了她的死亡。这个时候故事迎来了第一个反转——在朱实去世后，谅一突然提出他有不在场证明。因为在火灾发生后，他曾今与一位戴着墨镜头顶假发的女子在一家旅馆同居，并且旅馆工作人员也证实，谅一脸上的烫伤是在旅馆弄的。最终谅一被无罪释放。在谅一被释放后不久，谅一被发现死在别墅中，并且警方发现他被人从楼梯上推下，但是他真正的死因却是砷化物中毒。并且谅一开过来的车子也被烧毁。此时故事进入到两名女子的回忆中，首先是谅一的小姨子，也就是朱实的妹妹幕叶。通过幕叶的回忆，此时我认为是朱实女士提前在峰岸老人酿造好的梅子酒中下毒，因为她知道谅一喜欢这种酒，并且在她利用自己的死成功报复了谅一。而且幕叶有一个表弟名叫启太。因为家庭缘故，启太慢慢变成了一个不良少年，但是因为从小受舅舅启治的疼爱，所以幕叶一直对启太很好，并且他们之间的姐弟关系也维持的不错，但是在一天早上幕叶发现启太居然开车撞向她，想置她于死地。幕叶怀疑与谅一在火灾发生那一晚同居的女性是佳苗。由此引入了今村佳苗的回忆。佳苗与启治是重组家庭，因为启治的前妻久子患有精神类疾病，所以与久子离婚后与佳苗再婚了。同时佳苗带来了一个女儿——美土里。启治再婚后，启太露出了叛逆的一幕，因为他之前与父亲表面关系好，仅仅是希望父亲不要抛下生病的母亲，但是父亲再婚后，他的幻想彻底破灭，并且从此学坏了，不光逃课逃学，后面小偷小摸，并且与帮派扯上关系。几年之后美土里也离家出走，与帮派的一位少爷同居了，为了请求帮派拆散他们二人并且让美土里回来，启治只能找到有帮派有关系的人从中周旋并且借了2000万的高利贷。虽然女儿回来了，但是高利贷压得他们一家喘不过气来。只好向峰岸老人借钱。在债务问题眼看着要解决的时候，谅一表示他代表岳父峰岸老人来要债，最终启治卧轨自杀。在启治自杀后，美土里又离家出走了。并且佳苗在打扫女儿的房间时发现了墨镜和假发，原来那天与谅一同居的人是美土里。并且这个时候美土里的男友也找上门来。前面给出的各种推理用的线索，让人目不暇接。这个时候侦探登场了，随着侦探的登场，真相也在这一刻揭秘。本书在设置谜题这块我觉得有所欠缺，它并不是那种传统推理小说中的谜题，反而是一个社会中常见的凶杀案。而且最后结尾处强行将所有人融成一个圈子，虽然这个伏笔令人眼前一亮，但是感觉经不起推敲。不过我没看过前面的几作，所以这里不做过多的评价。但是它并不是我期待的那种推理小说，除了有案件、有侦探，我感觉不出来有什么额外的推理元素。也没有读后那种解开真相的爽快感。只有简单的“哦，原来是这样啊”，这种平淡。

Emacs 折腾日记(二十三)——进一步提升编辑效率 在前面的几篇，我们完成了Emacs的vim模拟器、中文输入、多行编辑以及基本的补全功能的添加。这一篇没有具体的提升哪一方面的能力，这一篇我想整合我在其他教程中看到的我认为对我比较有用的用法和插件，算是对前期功能的一个总结。让Emacs记住一些信息一般的编辑器都会在下次打开时记住上次的一些信息，例如记住之前打开过的文件，执行过的命令，或者记住上次的窗口布局。记住上次执行的命令我们每次使用 M-x 执行命令时，minibuffer中显示的提示都是一样的，那些常用命令要么不在上面要么太靠下了，我们希望能记住某些命令，以便能快速找到它。记住上次执行的命令可以使用 savehist 插件。它是一个Emacs自带的插件，默认是关闭的状态，我们可以通过将 use-package 来加载它，但是因为是自带的，不需要从镜像中下载所以它的 :ensure 项应该设置为 nil(use-package savehist :ensure nil :hook (after-init . savehist-mode) :custom (savehist-file (locate-user-emacs-file "custom/savehist")) ;; 设置保存文件的位置 (savehist-additional-variables '(kill-rings shell-command-history)) ;; 额外保存剪切板和shell命令行历史 (savehist-ignored-variables '(message-history)) ;; 不保存消息历史 (history-delete-duplicates t) ;; 自动去重 (history-length 1000) ;; 保存历史数据条目 )在执行一些操作关掉Emacs之后，我们会发现它在 ~/.emacs.d/custom 生成了一个名为 savehist 的文件，它记录了之前在minibuffer中执行的命令。为了保持git工程的干净，我打算将这种历史文件排除在git管理之外，所以单独将它放到custom目录，并忽略它其实该插件不光可以保留执行的命令，minibuffer中的许多信息它都可以保存和持久化。minibuffer-history (所有 minibuffer 输入历史)command-history (执行过的命令)search-ring (搜索历史)regexp-search-ring (正则搜索历史)extended-command-history (M-x 命令历史)file-name-history (文件路径历史)记住上次打开的文件一般的编辑器都可以记录上次打开的文件，并列出来。Emacs也有一个类似的内置插件—— recentf(use-package recentf :ensure nil :hook (after-init . recentf-mode) :custom (recentf-max-menu-item 10) ;; 最多只记录10条历史记录 (recentf-save-file (locate-user-emacs-file "custom/.recentf")) ;; 定义保存历史记录的临时文件路径 )搜索功能的增强实现全局搜索我们可以依赖Linux上的命令行工具 grep 和最近(也不算近了)的 ripgrep。之前在介绍vim的时候，vim内部集成了 grep。但是我们使用更为强大的 ripgrep。在Emacs中可以配合插件 consult 和 ripgrep，调用 consult-ripgrep 来进行全局搜索。它会自动搜索当前项目下的所有目录。我们对之前 consult 插件的配置代码进行一些修改，并添加 ripgrep 的配置(use-package consult :ensure t) (use-package ripgrep :ensure t :after consult :bind (("C-s" . consult-ripgrep)) )这里我们将 C-s 绑定的快捷键修改为 consult-ripgrep。神奇的是，配合之前安装的orderless，我们只需要按照一个模糊的记忆来匹配想要的内容。同时它也能支持输入中文批量替换批量替换这个功能，根据我找到的教程，它需要依赖 embark、consult、和 wgrep 这么三个插件。其中 consult 用来进行搜索，而 embark 可以为不同场景下的文本/候选项（如搜索结果、补全列表、文件路径等）提供动态的快捷操作菜单。简化了minibuffer上的一些操作。而 wgrep 则是其中的核心插件，用来批量修改内容并保存(use-package embark :ensure t :after consult :bind (("C-e" . embark-export))) (use-package embark-consult :ensure t :after embark) (use-package wgrep :ensure t :custom (wgrep-auto-save-buffer t) ;; 自动保存修改 )这里我们使用 :after 来保证插件的加载顺序依次为 consult、embark、embark-consult，特别是 embark-consult，它依赖 consult 和 embark，一定要将它放到后面加载。下面来演示如何进行批量替换，这里我们将配置中所有 use-package 修改为 package-install，修改之前记得使用git等版本管理工具进行备份首先，使用 C-s 搜索 use-package 关键字接着使用 C-e, 也就是上面绑定的快捷键来将结果从 minibuffer 导出到 buffer然后使用 C-c C-p 调用 wgrep-change-to-wgrep-mode 将 buffer 的mode由 grep-mode 修改为 wgrep-mode接着使用 M-% 调用 query-replace 进行替换，这个时候它需要输入被替换的字符和替换后的字符确定后，对于每个待替换的位置使用 y 或者 n 来表示替换或者不替换。也可以使用 ! 替换所有最后使用 C-c C-c 调用 wgrep-finish-edit 来结束编辑，配置之前设置的自动保存，此时修改内容已经被保存了修改之后如何不满意，可以使用 C-c C-k 撤销修改小节这应该是最后一篇关于Emacs自身编辑功能的增强了，在这一块我没有使用太多的Emacs经验。倒是在vim上有点经验，所以很多东西我不自觉地就往vim上面靠，总想着vim在编辑上有些功能Emacs上还没有，该如何进行添加，这几篇就显得比较分散，总是想到什么功能就往上面堆。为此造成各位读者阅读体验不佳，我表示道歉。谢谢各位读者的支持和鼓励！

读 《南京大屠杀》 这本书是我收藏在书架上好久都不愿意读的一本书。因为它里面的内容是如此的沉重。作为一个历史上著名的事件，从中学课到各种记录片，都描述了在这个事件中，敌人是多么的残酷，多么的灭绝人性。而且据说作者还因为这本书导致精神出现问题，最终因为精神问题自杀。我不知道在读完这本书之后会是怎样的心情。但是借着五一这段假期我没什么事，索性读完它。本书分为3个部分，分别讲述了历史上的南京大屠杀，从日本人的角度如何看待南京大屠杀，以及一些国际友人在这场浩劫中采取的救助行动。书中从各个角度，详细的描述了南京大屠杀的惨状。在读这本书的过程中，我时不时停下来，想想书中描述的场景，与之前看过的记录片联系起来。我很难想象这些暴行是出自人类之手，日本人就是未进化的野兽，卑鄙下作的下等人，我实在是找不到合适的词语来形容这种暴行。我想正常人类的文字应该无法准确的描述当初国人的惨状，任何人在看完相关记录之后能心平气和的看待日本和日本人。但是我们不应该一棒子打死所有日本人，书中虽然没有记载，但是我们记住了很多拥有共产主义精神和国际主义精神的日本人，在那段历史中仍然有部分日本人及时醒悟过来并且投入到反抗帝国主义暴行的运动中来。毛主席高瞻远瞩的写出“中国人民和日本人民的敌人是一致的，都是日本帝国主义以及中华名族的败类”。南京大屠杀是任何中国人都不应该忘却的惨痛历史，我实在是不太想详细的记录这本书的一些细节。首先这本书里面的内容之震撼不是简单的就能概括的，真正的震撼应该要亲自阅读这本书。另外这本书里面写的内容在没有做好心理准备之前是不适合阅读的，在阅读的过程中我总是要停下来狠狠的骂一下日本人才能继续阅读，不然我心理实在过意不去。个中滋味我想只有在阅读的过程中才能体会到。我对日本这个名族一直很矛盾，日本有优秀的电影、音乐、文学、游戏、动漫等文化产业，但同时又是一个充满野心，又保留军国主义的国度。我想还是毛主席说的对，我们应该仇恨军国主义，日本的右翼思想。而不应该仇恨普通的日本人。他们与我们一样，承受了战争的痛苦和苦难。

Emacs 折腾日记(二十二)——补全强化 在之前的一系列文章中，我们对Emacs做了一些小范围的定制，目前它已经可以很好的模拟vim的一些基础功能。我们也在模拟vim基础功能之上做了一些能力的提升。本篇我们将对Emacs自带的补全系统做一个升级，并且给出一些搜索和替换的方案，进一步提升Emacs的效率Emacs上有很多很好用的补全插件，著名的有前期的 ivy 体系和当前社区比较火的vertico 体系。为了与时俱进，而且Emacs-China中的很多帖子也推荐使用vertico，所以这里我也介绍这个体系中的插件。vertico 体系中包括下面几个插件:verticoconsultcorfumarginaliaorderlessconsultconsult 插件提供了一系列的查找和补全命令(use-package consult :ensure t :bind (("C-s" . consult-line)))这样我们可以通过使用 C-s 来进行搜索vertico默认情况下，我们使用M-x 输入命令时没有补全提示，但是可以使用TAB 键补全。我们可以通过命令 icomplete-mode 来启用这个mode，以便在输入命令时能拥有一个补全。但是这个补全采用的是横向排版的方式，显示上也不太直观。这里我们可以通过vertico 插件对补全进行增强。vertico 提供了一个垂直样式的补全系统。我们可以通过下列代码来安装并启用它(use-package vertico :ensure t :hook (after-init . vertico-mode))重启emacs之后，再执行 M-x 之后发现它已经可以竖直的显示命令，并且会列出可能的命令了。可以使用 C-n、C-p 来选择下一个或者上一个命令orderless顾名思义，orderless 提供一种无序补全。它可以将一个搜索的范式变成数个以空格分隔的部分，各部分之间没有顺序，你要做的就是根据记忆输入关键词、空格、关键词。它改变了我们使用和思考的习惯，我们不再需要关心信息的顺序，我们只需要在脑海中搜索关键信息片段，然后把这些片段组合起来即可，剩下的都交给Emacs。例如我们要输入 package-refresh-contents 来刷新包管理里面的源。常规的做法我们需要先输入 pack 等等字符，然后由补全信息给我们提示，加入 orderless 之后，可以凭借模糊的记忆输入类似 refre pack 这样的片段来进行匹配(use-package orderless :ensure t :init (setq completion-styles '(orderless)))orderless 是针对整个minibuffer进行增强的，只要是使用minibuffer的地方都可以使用。例如我们上面使用了 consult 插件并且绑定了 C-s 来进行搜索，这里我们就可以使用orderless 来配合完成搜索功能marginaliamarginalia 可以给minibuffer中候选条目显示一段注释或者其他信息。其实不光是执行命令的时候marginalia是启用的，现在只要是minibuffer中的选项，marginalia都是可以使用的，例如使用 switch-buffer 和 find-file 或者使用帮助信息的时候也可以展示相关信息corfucorfu 可以让我们通过弹窗进行补全。(use-package corfu :ensure t :hook (after-init . global-corfu-mode) :custom (corfu-auto t) (corfu-auto-deply 0) (corfu-min-width 1) :init (corfu-history-mode) (corfu-popupinfo-mode))在安装完成之后，我们在编写相关配置的时候可以配合orderless，只输入函数的部分，仅仅凭借模糊的记忆让Emacs自己来匹配我们想要的内容，极大的提高了输入的效率capecorfu 插件仅仅是一个补全的前端，它需要补全后端提供数据。好在Emacs 自己提供了有关elisp 的补全后端，所以上面在测试corfu补全的时候可以出现。但是在其他文本类型不会产生补全选项。而cape则是集成了多种补全后端，它与corfu联合起来可以起到很好的补全效果(use-package cape :ensure t :init (add-to-list 'completion-at-point-functions #'cape-dabbrev) (add-to-list 'completion-at-point-functions #'cape-file) (add-to-list 'completion-at-point-functions #'cape-keyword) (add-to-list 'completion-at-point-functions #'cape-ispell) (add-to-list 'completion-at-point-functions #'cape-dict) (add-to-list 'completion-at-point-functions #'cape-symbol) (add-to-list 'completion-at-point-functions #'cape-line))上述代码中 completion-at-point-functions 保存的是Emacs在补全时调用的相关函数来获取补全项，我们将cape 的相关函数添加到这个列表中，供Emacs在触发补全时调用。到此为止，我们对Emacs自身的补全进行了加强。进一步提升了编辑的效率

读《经济学通识》 本书是薛兆丰之前发表过的有关经济学相关文章的一个集合。这些文章利用经济学知识分析相关的社会的问题，在实践中学习经济学。之前我看过一些经济学相关的书籍，那些要么是文绉绉的理论看的人头大，要么是浅尝辄止，感觉不到相关的点。这一系列的文章通过社会问题来聊其中涉及的经济学知识，在实践中学习。算是一本比较好的入门经济学的书籍。书中也不乏很多妙语。下面我截取一些我比较喜欢的句子来谈谈自己的看法例如开头就说人生至少面临4项普遍约束：（1）东西不够；（2）生命有限、（3）互相依赖、（4）需要协调。这四项对应着四类经济学理论：（1）需求定律；（2）利息理论；（3）制度理论；4（宏观理论）。仔细想想，总结的这四项约束实在是太精辟了，特别是东西不够和生命有限。我们无时无刻不在面临着东西不够的窘境。大到教育、医疗、国家的资源；小到到底今晚是吃火锅好还是吃炒菜好。我们面临着普遍的选择问题，而经济学就是为了计算每种选择的成本与收益，帮助我们做决策的。一般的一个不“认钱”的社会，它就不得不“认人”当需求无法通过价格反馈给市场时，就必然会造成物质短缺。如果不通过价格来分配物资，就会有一套严格的制度来对人划分369等，按等级分配。一旦需要人为的区分需求，必然会导致权力的腐败。有一句名言：“权力不会向穷人敞开，而金钱会”供求先决定产品的价格，而最终产品的价格再来决定原材料的成本虽然下意识的认为，商家会在成本的基础上提价并作为商品最终的售价。但是根据需求理论，价格是由需求决定的。商家也只能根据需求定价，然后在这个定价的基础之上压缩成本价。成本太高最终会导致商品因为价格过高而无人问津。任何国际贸易，都不仅会使得交易双方双赢，还导致生产效率较低的第三方受损交易的双方是共赢的，而会损害未成交的其他潜在商家的损失。一般来说商家与商家才是竞争对手，同样的客户与客户间也是竞争关系汇率是由甲国人民对乙国资源的需求，以及乙国人民对甲国资源的需求共同决定的。这里还是可以用需求理论来解释，当一国对另一国资源的需求提升，那么对它国货币的需求就会提升。也就是说它国货币会增值。耐用品的现值，取决于人们对其未来效用的预期。一项资产的价值，总是它未来收入的折现，而过去投入的成本是沉没成本，不论大小都不影响资产的现值典型的应该是股票这一资产的价值，股票升值并不是说当前公司有价值，而是人们认为公司未来会比较有价值。所以永远无法评估明天股票是涨还是跌。因为参与市场交易的每个人对公司未来价值都有不同的评估方式。同样的我们投资一个孩子的教育并不是说孩子现在很出色，而是通过教育孩子的未来大概率会出色。普通人有四种办法增加收入：挣钱、借钱、卖家当、抢钱；而政府增加收入的方式也有四种：挣钱、借钱、卖家当，不然就是征税和印钱。先谈挣钱。古今中外的经验告诉我们，政府不善于挣钱，尽管政府官员可以很聪明，政府可以拥有海量的市场数据，政府也具备做事的魄力，但致命之处是：政府官员不是公共资源的私有者，他们对资源利用的决策，可能只顾任期之内的效果，不可能看到遥远的未来。“争取和保住位置”是他们的目的，“做事”是他们的手段；而不是相反，他们不可能把做事当作目标，而把“争取和保住位置”当作手段，不是说政府官员中缺乏志向高远之人，而是说政治的现实约束，决定了官员必定“先占位置，始能做事”花自己的钱办自己的事，花别人的钱办自己的事、花自己的钱办别人的事、花别人的钱办别人的事，效率是依次递减的人的思想五花八门，而人的行动却大同小异；因为前者不用承担代价，后者承担代价。不要看一个人怎么说，而要看他怎么做。很多时候，经济学确实如作者是所说，是一门提升认知，给自己洗脑的学科。通过学习经济学，对一些社会现象有了一定的认知。同时也可以指导我们如何做决策。小到今晚吃什么、大到一生于谁为伴。其实都可以利用经济学相关知识，在权衡利弊之后行动。行动是要付出代价的，天下没有免费的午餐，即使有，也需要付出时间于其他人去竞争。

Emacs 折腾日记(二十一)——编辑能力提升 上一篇文章，我们补充了一些基本的配置，并且关闭了一些默认的行为。这里我们继续对它进行配置。本篇将要使用一些插件来修改默认的编辑行为进一步提高编辑文本的效率。avy 插件基础用法在vim中有 easymotion 可以使用，在Emacs中可以使用 avy 插件。它的功能于前面介绍的easymotion 类似。通过下面的代码来安装(use-package avy :ensure t :after general ;; 确保 general 插件已经安装 :config (setq avy-timeout-seconds 0.5) (my-leader-def "f" 'avy-goto-char-timer))我们在安装配置的时候使用之前定义的leader键来定义它的一些行为。首先定义 SPC-f 来进行快速跳转。avy-goto-char-timer 的功能与 easymotion 类似，将要查找的字符使用不同的字母进行标识，然后根据下一步的输入来确定光标的位置，例如下面的例子我们可以连续输入一段内容减少待筛选项。当然这个速度要快，否则在一定时间内没有输入文本之后，avy会认为已经结束输入了。这个等待的时间我们在上面通过 avy-timeout-seconds 定义的是 0.5。当然也可以扩大这个时间范围进阶用法这个简单的功能只是 avy 功能的冰山一角。它还有许多有用的功能，如果能熟练使用将会极大的提高编辑文本的效率。实际上avy 在筛选、跳转之前可以执行用户指定的动作，它支持哪些动作呢？我们可以在输入筛选的部分文本后输入?，查看支持的动作。我们来举一个例子：下面有一段文本，我希望将text1复制到最后一行，那么可以这么操作使用<leader>f 激活 avy，然后输入筛选文本输入 Y 表示复制整行输入对应字符表示选中text1 所在行此时我们会发现，text1 已经被复制到光标所在行了多行操作和块操作在vim中我们介绍了多行操作，主要是使用C-v 来选中某些行，然后通过使用A 或者 I 来选中行尾或者行首，并进入插入模式。这种方式可以同时在对应位置插入多个相同的字符。emacs 中的 evil 插件也可以进行相同的操作。但是对于行间或者每行在不同位置插入的情况就不适用了。我们可以使用插件 evil-multiedit 来达到这一效果。evil-multiedit 深度绑定了vim的快捷键，在选中区域之后可以直接使用vim中的 I/A 来编辑选中区域的首部或者尾部。也可以使用 ciw 之类的同时修改多个选中区域。在选区时既可以使用vim 中的 * 来查找并选中，也可使用 / 来搜索并且同时选中多个。这个插件相当于增强了vim的多行编辑功能我们使用下列的代码来安装和简单的配置(use-package evil-multiedit :ensure t :after evil :config (evil-multiedit-default-keybinds) (my-leader-def "m m" #'evil-multiedit-match-and-next ; 标记当前符号并跳转下一个 "m M" #'evil-multiedit-match-and-prev ; 标记当前符号并跳转上一个 "m a" #'evil-multiedit-match-all ; 标记所有相同符号 "m r" #'evil-multiedit-restore ; 恢复单光标模式 "m c" #'evil-multiedit-toggle-or-restrict ; 切换选区/限制编辑区域 ))我们可以使用 <leader> mm 来选中符合条件的项也可以使用 <leader> ma 来选择所有符合条件的项好了，本节到此也就结束了，本节依靠两个插件，进一步模拟vim相关的功能，并且对vim原有的功能进行了一定程度的补强。熟练使用这两个插件将会对编程的效率有一个进一步的提升。作为一个普通的文本编辑器也足够了。

读 《莫兰传》 这个标题看着像一个人物传记，但是实际上它是一系列的推理小说。这个系列的小说是我之前在网上找到的鬼马星作品集。说到这个作者，我还是从高中时期买过的一些推理小说杂志上听说的。之前只在杂志上零星的看过一些片段，只知道是一个中国的作家。这是第一次全面的阅读她的作品。这个作品集中当然不止 《莫兰传》这一个系列，还有好几个系列，但是长时间读同一个风格的作品难免有些审美疲劳，我想先暂停一下其他内容的阅读，看看其他的书籍，到后面无聊的时候再往后继续读。《莫兰传》主角当然是莫兰，她出生在一个家境优渥，父母恩爱的家庭。而男主角高竞从小经历了父亲去世，母亲将父亲去世归咎于他并且从此不待见他，而他的妹妹也是一个只知索取却从来没有感恩过哥哥的自私自利的人，好在出生并成长在这样家庭中的高竞并没有因此消沉或者走入歧途，相反他却是一个热心肠并且极富正义感的好警察。这个系列就是围绕着男女主互相配合侦破一系列迷案展开的。书中一直穿插着描述了主角莫兰和高竞的感情线。从20岁高竞见到莫兰一见钟情到最后女主成年后二者修成正果。这些感情线同样充斥了误会的争吵，二人在一起时的甜蜜，有种看言情小说的味道。但也是紧张案件中间的调味剂，使人因为案件紧绷的神情能有丝丝的放松，甚至会因为二人间的甜蜜日常会心一笑。与其说这一系列的侦探是莫兰，不如说是二人组都在案件中扮演者各自的侦探角色。作者擅长多视角叙事，经常在莫兰、高竞、凶手和其他第三方人员的视角间切换，并且在切换中从不同人的视角中给读者一些用于推理的线索。在《隔墙玫瑰》这个案件中，因为高竞失忆，作者在两人间的视角切换进行的极为自然，最终导向真相，最终二者携手破案。并且最终作者给了高竞一个很好的结局。高竞因为失忆忘记了成年前的记忆，算是摆脱了原生家庭的桎梏，迎来了新生。要最令人失望的要数《宴无好宴》，这个案子开头确实挺吸引人的。四个月前探员李耀明被杀，警察局档案室警员乔纳的同事若琳约乔纳在某个茶餐厅见面，并且讲述了丈夫最近的一些异常。但是在乔纳中间离开一段时间之后若琳被杀。随后若琳的丈夫也被人从地铁站台推下，被人谋杀。并且在其中还牵涉出警局的内鬼，以及背后的黑色势力——司徒雷。开局这么吸引人，但是随着故事的推进，也越来越无聊。主副线剧情混乱，在前面几部塑造的人物形象完全变了样，只是为了男女主之间的感情线服务，男女主之间也似乎是为了谈恋爱而谈恋爱。这部书中充斥着爱情，似乎正义、真相都为了爱情让步。最后的也是草草结束，感觉作者在憋大招结果确给我来了个大的。虽然这一系列有这样那样的缺点，但是却不失为一本好的小说，故事性也足够。就像东野圭吾那样神一本鬼一本，作者也不可能每本都优秀。作者塑造的人物也是个性鲜明。作者的推理小说具体是什么派别，到底是本格派、社会派还是其他的我也说不准，但是给我的感觉有点像看柯南。推理只是服务于剧情，服务于人物塑造。我倾向于叫这个风格为偶像派推理小说，将来改编成电视剧，男女主弄些流量小生、俊男靓女，谈着恋爱就把案子破了，这系列小说给我的就是这么一种感觉。作者有中国的“阿加莎”之称，但是我感觉这系列的作品还达不到阿婆的高度。其实写小说特别是推理小说的读后感写不了多少字，其他的小说介绍一下大概的情节，再分析一下人物感觉就很圆满。但是推理小说最大的魅力就是当你什么都不知道随着阅读的深入，跟着作者的节奏，最后恍然大悟那一刻。要是提前被剧透了一些细节，阅读的快感就大打折扣了。

读 《沉默的大多数》 早些时候看到网上有人说可以读王小波的书学习一下怎么写作。所以我找了这本书看了一下。但是看完给我的感觉一般。这是一本杂文集，里面的文章确实式杂文，给我的感觉就是整个文章的节奏都比较杂，想到什么就说什么。但是大部分内容又很贴合文章标题，都在围绕一个主题在谈。这个可能就是杂文的一个形式。说实话我对于一般的文学作品做到很深的品评。我对于文学的造诣也一般，文学作品对我来说只有谈论的话题是不是我感兴趣的，讲的故事是不是比较有趣的。文学作品里面哪些句子写的漂亮，我能学到什么，这点我完全没有感觉。这本书里面大部分的文章我都不怎么感兴趣，特别是中间关于国外生活的。不知道作者是不是因为早些年知青下乡插队的经历，作者在很多文章中都有一种知识分子对普通农民的一种优越感，总喜欢通过那段经历来论证自己与普通人的不同。虽然从中可以看到作者的一些思考和对一些经历的反思，但是读起来我感觉一般般，虽然说不上坏但是也不算好。真正我比较喜欢的就两篇 《花剌子模信使问题》和 《沉默的大多数》。下面就谈谈我对这两篇文章的感受《花剌子模信使问题》花剌子国有一个奇怪的风俗，凡是给国王带来好消息的信使都能得到升迁，给国王带来坏消息的信使最终都会被惩罚甚至被送去喂狮子。时间久了国王那里就只能听到好消息了，但是坏消息是不是不存在呢？当然不是。文章通过这一个预言故事来警示人们，不能只听好消息，或者只喜欢给自己拍马屁的人，又或者害怕得罪人，只讲好话不讲坏话。这些都有问题，最重要的是要客观的看待问题，我想这就是我在中学时学习到的“实事求是”。当初一直以为有什么说什么，实事求是本来就很容易，自己就是这么做的，这是一句废话，专门讲这个有点浪费时间。但是随着自己年纪的增长，以及混社会的日子越来越久，对这个词的认识也越来越深。实事求是最重要的就是客观，客观的看待人，看待事。有时候并不是我们故意不客观，故意高估或者低估，而是本身对事物的认识就不足。因为我们潜意识里面都偏好好消息，例如明明没有财务知识，金融知识，恰巧进入股市赚了一点钱，这个时候大脑就简单的给我报告了一个好消息，我是股神，我判断的是对的。又或者自己这些年吃到了时代红利，挣了不少钱。这时候好消息就来了，这个好消息就是我高人一等。看着这些“不求上进”的年轻人，不找工作居然想躺平，作为“成功人士”自然看不惯这种行为，想当然的去批判他们。寓言故事很简单，当然国王也很傻。我有时候也自信我比故事中的国王高明，但是在潜意识里面我可能也当过这样的国王，我的大脑自动过滤了好消息而忽略的坏消息。我想要提升自己这方面的能力还是要保持客观，多学一点其他方面的知识。很多时候换一个角度，换一种知识分析同样的问题，可能就能得到好消息或者坏消息。《沉默的大多数》作者在这篇文章中点出中国人大多数比较沉默，而且也分析了自己比较沉默的一些理由。这里我就不列举这些理由了。我喜欢这篇文章主要是我有一些共鸣。其实不光是我，网络上大部分网民都是沉默的大多数。很多网民都是只看不发言，特别是在一些两方对立比较激烈的情况下，他们只看不站队，也不发言。当然我也佩服那些能引经据典，口若悬河，妙语连珠的人。我在生活中也是一个沉默的人。首先我觉得一个人在人群中什么都想说几句，什么都能说几句，必然是会在人群中比较显眼。这种人一般是群体的中心。但是我不太喜欢这样，或许是我不喜欢那种引人注意的感觉，特别是陌生人注意到我会让我觉得很不自在，也可能是我害怕在公众面前因为说错话而出丑，还可能是我不想因为说了一些争议的话引来别人的辩论或者人身攻击。还有一个原因，随着年岁的增长自己也慢慢的觉察到当初的一些观点和认知错的离谱，如果当初在朋友或者陌生人面前侃侃而谈，而今发现自己曾今是多么的幼稚，错的多么离谱。这段往事就是自己的黑历史了，而且也是徒增笑料罢了，还不如保持沉默。另一个原因就是这些年自己也读过一些书，总是有种这个世界太复杂而我自己懂的太少。相同的事，不同的人能从不同的角度分析得到完全不同的结论，而且都有证据和推理过程来论证自己的结论，世上高人这么多，哪轮得到我这种小卡拉米来发表什么高论。所以在网络上我也是沉默的大多数。但是一个人不说话总是闷着也怕憋坏了。所以我建立了一个自己的博客，有时候这里说点心里话，也写点自己想说的，算是给自己一个说话的渠道。以上都是我个人的自言自语，有胡说八道的成分在里面。各位读者看了就行，不要来反驳我或者人身攻击，也请日后不要拿这些矫情的文字来取笑我！

使用CMake跨平台的一些经验 使用CMake构建工程的一个原因是不希望Windows上有一个工程文件，Linux又单独配置一套工程文件。我们希望对于整个工程只配置一便，就可以直接编译运行。CMake本身也具备这样的特性，脚本只用写一次，在其他平台能自动构建工程。这里谈的跨平台主要是如何组织工程和编写CMake来针对Windows和Linux进行一些特殊的处理，在这里说说我常用的几种办法介绍这些方法的前提是有一些代码只能在Windows上跑，例如调用Win32 API或者使用GDI/GDI+，而在Linux上也有一些Windows不支持的代码。我们就需要一些方法来隔离开这两套代码。假设现在有一个项目，它有一套共同的接口对外提供功能，而在Windows上和Linux上各有一份代码来实现这些接口。可以假设有一套图形相关的功能，对外采用统一的接口，具体实现时Windows上使用GDI+，而Linux上使用其他方案来实现。现在整个项目的目录结构如下. ├── include └── platform ├── linux └── windowsinclude 目录用来对外提供接口，是导出的头文件。platform隔离了Windows和Linux上的实现代码。使用宏来控制我们知道Windows和Linux平台有特定编译器定义的宏，根据这些宏是否定义我们可以知道当前是在Linux还是Windows上编译，是需要编译成32位或者64位程序，又或者编译成debug版本或者release版本。例如下面是我用的简单的判断版本的方式#define MY_PLATFORM_WINDOWS 0 #define MY_PLATFORM_LINUX 1 #define MY_PLATFORM_APPLE 2 #define MY_PLATFORM_ANDROID 3 #define MY_PLATFORM_UNIX 4 #define MY_ARCH32 1 #define MY_ARCH64 2 #if defined(_WIN32) || defined(_WIN64) #define MY_PLATFORM MY_PLATFORM_WINDOWS #ifdef _WIN64 #define PLATFORM_NAME "Windows 64-bit" #define MY_ARCH MY_ARCH64 #else #define PLATFORM_NAME "Windows 32-bit" #define MY_ARCH MY_ARCH32 #endif #elif defined(__APPLE__) #include "TargetConditionals.h" #define MY_PLATFORM MY_PLATFORM_APPLE #ifdef ARCHX64 #define MY_ARCH MO_ARCH64 #else #define MY_ARCH MO_ARCH32 #endif #if TARGET_IPHONE_SIMULATOR #define PLATFORM_NAME "iOS Simulator" #elif TARGET_OS_IPHONE #define PLATFORM_NAME "iOS" #elif TARGET_OS_MAC #define PLATFORM_NAME "macOS" #endif #elif defined(__linux__) #define MY_PLATFORM MY_PLATFORM_LINUX #if defined (ARCHX64) || defined (__x86_64__) #define MY_ARCH MY_ARCH64 #else #define MY_ARCH MY_ARCH32 #endif #define PLATFORM_NAME "Linux" #elif defined(__unix__) #ifdef ARCHX64 #define MY_ARCH MY_ARCH64 #else #define MY_ARCH MY_ARCH32 #endif #define PLATFORM_NAME "Unix" #define MY_PLATFORM MY_PLATFORM_UNIX #else #error "Unknown platform" #endif上面代码根据一些常见的编译器宏来决定是什么版本，并且根据不同的版本将MY_PLATFORM 进行赋值。后面只需要使用 MY_PLATFORM 进行版本判断即可。同样的关于架构使用 MY_ARCH 来判断。例如根据架构来定义不同的数据长度#if (MY_PLATFORM == MY_PLATFORM_WINDOWS) typedef __int64 MY_INT64; typedef unsigned __int64 MY_UINT64; #else typedef long long MY_INT64; typedef unsigned long long MY_UINT64; #endif #if (MY_ARCH == MY_ARCH64) typedef MY_UINT64 MY_ULONG_PTR; typedef MY_INT64 MY_INT_PTR; #else typedef MY_UINT MY_ULONG_PTR; typedef MY_INT MY_INT_PTR; #endif定义的常见的数据结构之后，对于一些接口的视线就可以利用宏来隔开// platform/windows/image.c #if (MY_PLATFORM == MY_PLATFORM_WINDOWS) // todo something #endif// platform/linux/image.c #if (MY_PLATFORM == MY_PLATFORM_LINUX) // todo something #endif这样我们可以利用上一节介绍过的 cmake 的 file 或者 aux_source_directory 将整个platform目录都包含到工程里面。使用cmake来判断版本除了在C/C++ 源码中利用编译器特定的宏来判断版本，其实CMake自身也有一些方式来判断编译的版本。CMake 检测操作系统使用 CMAKE_SYSTEM_NAME 来判断。这里要提一句，CMake中的变量本质上都是一个字符串值，没有严格的区分类型，所以 set(variable 1) 和 set(variable "1") 在底层存储都是字符串 1。所以cmake在定义变量的时候可以不使用双引号，但是对于特殊的字符串，例如带有空格的字符串，为了避免语法上的歧义，可以带上双引号。虽然说底层存储的都是字符串，但是在上层判断变量是否相等的时候却又区分数字和字符串。判断变量是否等于某个值可以使用 EQUAL 或者 STREQUAL。EQUAL 是用来判断数字类型是否相等，一般判断版本号或者数字参数。而 STREQUAL 来判断字符串是否相等，一般用来判断配置选项、路径、平台标识符。例如这里的 CMAKE_SYSTEM_NAME 就需要采用 STREQUAL 来判断# 检测平台 set(PLATFORM_WINDOWS 1) set(PLATFORM_LINUX 2) set(PLATFORM_MACOS 3) if(CMAKE_SYSTEM_NAME STREQUAL "Windows") set(PLATFORM ${PLATFORM_WINDOWS}) elseif(CMAKE_SYSTEM_NAME STREQUAL "Linux") set(PLATFORM ${PLATFORM_LINUX}) elseif(CMAKE_SYSTEM_NAME STREQUAL "Darwin") set(PLATFORM ${PLATFORM_MACOS}) endif()判断架构可以使用 CMAKE_SIZEOF_VOID_P。顾名思义，它表示一个void* 指针变量的大小，8位就是64位，4位则是32位架构。if(CMAKE_SIZEOF_VOID_P EQUAL 8) set(PLATFORM_ARCH "x64") elseif(CMAKE_SIZEOF_VOID_P EQUAL 4) set(PLATFORM_ARCH "x86") else() message(FATAL_ERROR "Unsupported architecture pointer size: ${CMAKE_SIZEOF_VOID_P}") endif()至于判断当前编译的版本是debug 还是 release 可以使用 CMAKE_BUILD_TYPE 来判断，它的值主要有4个，分别是 Debug、RelWithDebInfo、MinSizeRel、Release。它们四个各有特色。其中 RelWithDebInfo 是带有符号表的发布版，便于调试，它的优化级别最低。MinSizeRel和Release在优化上各有千秋，前者追求最小体积，后者追求最快的速度，所以后者有时候会为了运行速度添加一些额外的内容导致体积变大。我们可以在cmake文件中判断对应的值以便做出一些额外的设置。例如if(CMAKE_BUILD_TYPE STREQUAL "Debug") add_compile_definitions(-D_DEBUG) else() add_compile_definitions(-DNDEBUG) endif()有了这些基础，我们可以在不同的条件下，定义不同的编译宏，然后根据编译宏的不同在C/C++ 源码中判断这些宏从而隔离不同平台的实现代码通过cmake list 来隔离不同平台的代码使用 file 或者 aux_source_directory 的到的是一个源代码文件的列表。我们可以操作这个列表来达到控制编译文件的需求。cmake 中针对列表的操作符是 list，它的定义如下:Reading list(LENGTH <list> <out-var>) list(GET <list> <element index> [<index> ...] <out-var>) list(JOIN <list> <glue> <out-var>) list(SUBLIST <list> <begin> <length> <out-var>) Search list(FIND <list> <value> <out-var>) Modification list(APPEND <list> [<element>...]) list(FILTER <list> {INCLUDE | EXCLUDE} REGEX <regex>) list(INSERT <list> <index> [<element>...]) list(POP_BACK <list> [<out-var>...]) list(POP_FRONT <list> [<out-var>...]) list(PREPEND <list> [<element>...]) list(REMOVE_ITEM <list> <value>...) list(REMOVE_AT <list> <index>...) list(REMOVE_DUPLICATES <list>) list(TRANSFORM <list> <ACTION> [...]) Ordering list(REVERSE <list>) list(SORT <list> [...])官方提供了这么一些操作list的操作符，但是在这个需求中我们只需要两个操作符APPEND 和 REMOVE_ITEM 即可。后面的参数分别是源列表，以及需要增加或者删除的项，它们都可以传入多项。但是删除时它是根据传入字符串，从列表中进行字符串比较，如果相等则进行删除。所以在传入路径的时候需要特别注意，不能一个传入全路径一个传入相对路径或者一个传入 / 开头的路径，另一个传入 ~ 开头的路径。上述两个操作都可以传入多个单个的字符串也可以传入一个列表。如果我们有下列目录结构src/platform/windows src/platform/linux src/*.cpp src/other/*.cpp也就说我们将不同平台的代码放入到src目录，并且src目录也有其他代码，我们如果使用 file 操作符来查找src目录中的源码文件必定会包含两个平台的实现代码。这个时候就可以考虑使用REMOVE_ITEM 根据平台来舍弃一些代码，例如file(GLOB_RECURSE SOURCES ${PROJECT_SOURCE_DIR}/src/*.c ) if(CMAKE_SYSTEM_NAME STREQUAL "Windows") file(GLOB_RECURSE NOT_INCLUDE ${PROJECT_SOURCE_DIR}/src/platform/linux/*.cpp ) elseif(CMAKE_SYSTEM_NAME STREQUAL "Linux") file(GLOB_RECURSE NOT_INCLUDE ${PROJECT_SOURCE_DIR}/src/platform/windows/*.cpp ) endif() list( REMOVE_ITEM SOURCES SOURCE ${NOT_INCLUDE} )又或者我们采用最上面的给出的目录结构，也就是说platform 目录位于src目录之外，相对于src来说是额外添加的代码文件，那么就可以使用 APPEND 来进行添加if(CMAKE_SYSTEM_NAME STREQUAL "Windows") aux_source_directory(${PROJECT_SOURCE_DIR}/platform/windows PLATFORM_SOURCE) elseif(CMAKE_SYSTEM_NAME STREQUAL "Linux") aux_source_directory(${PROJECT_SOURCE_DIR}/platform/linux PLATFORM_SOURCE) endif() list(APPEND SOURCES ${PLATFORM_SOURCE})通过 toolchain 文件来组织平台特殊配置cmake 允许我们在生成Makefile的时候指定toolchain 文件来实现一些自定义的配置。例如可以根据平台的不同将生成路径指定在对应的toolchain中。toolchain 的语法与cmake语法相同，例如针对Windows和Linux可以创建 win32_toolchain.cmake win64_toolchain.cmake linux_86_toolchain.cmake 和 linux_x64_toolchain.cmake 文件来区别我还是以上一篇文章中多工程嵌套的例子作为示例来演示如何使用，它的目录结构如下. ├── calc │ ├── add.cpp │ ├── CMakeLists.txt │ ├── div.cpp │ ├── mult.cpp │ └── sub.cpp ├── CMakeLists.txt ├── include │ ├── calc.h │ └── sort.h ├── sort │ ├── CMakeLists.txt │ ├── insert_sort.cpp │ └── select_sort.cpp ├── test_calc │ ├── CMakeLists.txt │ └── main.cpp └── test_sort ├── CMakeLists.txt └── main.cpp这个例子我们只需要改动根目录下的生成库和可执行程序的路径。cmake_minimum_required(VERSION 3.15) project(test) add_subdirectory(sort) add_subdirectory(calc) add_subdirectory(test_calc) add_subdirectory(test_sort)这个文件只需要保留最基础的配置即可，而生成程序的路劲都在 toolchain 中。下面是 linux_x86_toolchain.cmake 文件的内容set(LIBPATH ${PROJECT_SOURCE_DIR}/lib/linux/x86) set(EXECPATH ${PROJECT_SOURCE_DIR}/bin/linux/x86) set(HEADPATH ${PROJECT_SOURCE_DIR}/include) if(CMAKE_BUILD_TYPE STREQUAL "Debug") set(CALCLIB calc_d) set(SORTLIB sort_d) set(CALCAPP test_calc_d) set(SORTAPP test_sort_d) else() set(CALCLIB calc) set(SORTLIB sort) set(CALCAPP test_calc) set(SORTAPP test_sort) endif() set(CMAKE_SYSTEM_PROCESSOR i686) set(CMAKE_C_FLAGS "-m32 -L/usr/lib32" CACHE STRING "" FORCE) set(CMAKE_CXX_FLAGS "-m32 -L/usr/lib32" CACHE STRING "" FORCE) set(CMAKE_EXE_LINKER_FLAGS "-m32 -L/usr/lib32" CACHE STRING "" FORCE)这个文件我们定义了debug和release的库名称和生成的路径，并且指定相关参数用于生成32位程序。CMAKE 中定义了一堆 CMAKE_LANGUAGE_FLAGS 这些都是相关工具的参数，这里的FLAGS 分别是 gcc 和 ld 编译链接的参数。在使用时直接用命令 cmake .. -DCMAKE_TOOLCHAIN_FILE=../linux_x32_toolchain.cmake -DCMAKE_BUILD_TYPE=Debug 生成Makefile。Windows平台上上面的参数稍微有些差距。例如下面是 windows_x32_toolchain.cmake 的定义# 静态库生成路径 set(LIBPATH ${PROJECT_SOURCE_DIR}/lib/windows/x86) # 可执行程序的存储目录 set(EXECPATH ${PROJECT_SOURCE_DIR}/bin/windows/x86) # 头文件路径 set(HEADPATH ${PROJECT_SOURCE_DIR}/include) if(CMAKE_BUILD_TYPE STREQUAL "Debug") # calc库名称 set(CALCLIB calc_d) # sort 库名称 set(SORTLIB sort_d) # 测试程序的名字 set(CALCAPP test_calc_d) set(SORTAPP test_sort_d) else() # calc库名称 set(CALCLIB calc) # sort 库名称 set(SORTLIB sort) # 测试程序的名字 set(CALCAPP test_calc) set(SORTAPP test_sort) endif() set(CMAKE_GENERATOR_PLATFORM "Win32" CACHE STRING "Target Platform") # 指定32位编译器路径 set(CMAKE_C_COMPILER "$ENV{VCToolsInstallDir}/bin/Hostx86/x86/cl.exe") set(CMAKE_CXX_COMPILER "$ENV{VCToolsInstallDir}/bin/Hostx86/x86/cl.exe") set(CMAKE_SYSTEM_PROCESSOR x86)需要注意的是 CMAKE_GENERATOR_PLATFORM 对应的是VS 中的解决方案平台，也就是 Win32 和 x64 这两个选项。 而 CMAKE_SYSTEM_PROCESSOR 对应的是VS中的目标计算机选项，一般是X86、X64 或者 ARM64 和 AMD64。我们可以使用命令 cmake -G "Visual Studio 15 2017" -A "win32" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_TOOLCHAIN_FILE="..\windows_x86_toolchain.cmake" .. 这里指定使用 VS 2017 进行构建，构建架构是32位，版本是Debug。命令成功执行之后会生成一个.sln 文件，我们可以用VS打开然后在VS中编译，也可以执行使用命令 cmake --build . --config Debug 来编译。一般来说我习惯使用后者，过去使用vs 打开.sln 可以在vs中进行开发，如今vs 已经可以打开并编译cmake工程，所以现在我基本不使用 .sln 文件了，除非公司项目要求使用 .sln。好了，目前我掌握的关于cmake的内容就是这些了，我利用这些知识已经完成了公司项目的跨平台开发和部署。后续如果有新的需求说不定我会学点新的内容，到时候再来更新这一系列文章吧！！！

CMake 基础 很遗憾直到现在才开始接触cmake，过去都在微软的vs IDE上编写c++程序，即使引用第三方的库直接使用cmake也能编译成功，很少关注它本身的内容。但是现在我有一项工作的内容就是将在Windows平台上的c++程序移植到Linux平台上。我想选择cmake作为支持跨平台的构建工具。因此提前学了点cmake的基础知识。cmake本身并不能直接编译和链接程序，它是一个构建程序。主要作用就是根据cmake脚本来生成Makefile文件，以供nmake、gun make等工具来生成可执行程序。编译exe简单的hello world使用cmake需要提供一个CMakeLists.txt 的脚本文件，这个名称是固定的，位置一般在项目的根目录。假设现在有一个简单的hello world程序，它的项目目录可能如下v1 ├── CMakeLists.txt ├── main.cpp我们可以使用如下cmake脚本cmake_minimum_required(VERSION 3.15) set(CMAKE_CXX_STANDARD 11) project(test) add_executable(hello ./main.cpp)第一句的含义是指定使用cmake最小的版本为3.15；第二句的含义是使用c++ 11标准第三句的含义是指定项目名称第四句的含义是生成可执行程序的名称为hello，并且指定要编译的源文件是当前目录下的 main.cpp 文件。工程中有多个源文件时，add_executable 后面可以加多个源文件路径一般来说cmake脚本都会包含这么几条语句脚本编写完毕后，需要使用cmake命令进行编译。该命令可以接受一个参数用于指定CMakeLists.txt 文件所在的路径，执行之后会生成一大堆中间文件和对应的Makefile文件。这些都会生成在当前执行cmake命令时所在路径。所以为了便于管理，一般会在适当位置建立一个新的build目录。这个时候整个命令如下mkdir build cd build cmake .. make前面我们在项目根目录下新建一个build目录用于保存中间文件，然后切换到build目录中。接着执行cmake命令并给出对应CMakeLists.txt 所在的路径。执行成功后会在build目录中生成一个Makefile文件，最后就是执行make命令来生成可执行程序这样最简单的一个hello world工程就编译完成了。指定可执行程序的路径生成的可执行文件路径就在当前的build目录下，如果我们要指定可执行程序的路径，可以使用变量 EXECUTABLE_OUTPUT_PATH。它是cmake内置的变量，保存的是可执行程序输出的路径。在cmake中可以使用set来给变量赋值。到此我们的cmake脚本可能是这样的cmake_minimum_required(VERSION 3.15) set(CMAKE_CXX_STANDARD 11) project(test) set(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/bin) add_executable(hello ./main.cpp)这里涉及到cmake中变量的定义和使用。其实cmake中变量特别简单，cmake中的变量全都是字符串，定义和设置变量值都是用set 操作符。而要取变量的值则使用 ${} 来包住一个变量名。另外cmake使用 EXECUTABLE_OUTPUT_PATH 作为可执行程序的输出路径，这里我们设置输出路径为工程目录下的bin目录下面。这里的 PROJECT_SOURCE_DIR 表示的是当前项目的目录指定头文件所在路径这里我们来一个复杂一点的项目作为演示，这个项目的目录结构如下. ├── include │   └── calc.h └── src ├── add.cpp ├── div.cpp ├── main.cpp ├── mul.cpp └── sub.cpp这种工程中，include目录放头文件，src目录放源文件，calc.h 中定义了4个函数分别实现加减乘除四则运算。它们的实现分别在 add.cpp、sub.cpp、mul.cpp、div.cpp 中，而main.cpp主要负责调用这些函数实现。main.cpp 的代码如下#include <stdio.h> #include "calc.h" int main (int argc, char *argv[]) { int a = 30; int b = 10; printf("a + b = %d\n", add(a, b)); printf("a - b = %d\n", sub(a, b)); printf("a * b = %d\n", mul(a, b)); printf("a / b = %d\n", div(a, b)); return 0; }这里我们要解决一个问题，因为main.cpp在src中，而 calc.h在include目录中，它们并不在同一目录下，代码中直接引用它会提示找不到对应的头文件。我们当然可以写出 include "../include/calc.h" 来修正它，但是项目中文件多了，不同路径的源文件要写这种相对路径就是一种折磨了。一般的经验是给出头文件的路径，后面所有源文件都根据这个路劲来组织包含头文件的相对路径。这里我们需要指定include作为头文件的路径。cmake中使用 include_directories 来指定头文件路径，它可以接受多个目录表示可以从这些目录中去查找头文件。所以这个项目的cmake文件可以这么写cmake_minimum_required(VERSION 3.15) set(CMAKE_CXX_STANDARD 11) project(test) set(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/bin) include_directories(${PROJECT_SOURCE_DIR}/include) add_executable(hello ./src/add.cpp ./src/sub.cpp ./src/mul.cpp ./src/div.cpp ./src/main.cpp)遍历目录中的源文件上面的示例中我们发现 add_executable 后面加了好多cpp文件，这个项目比较小只有这么几个文件，如果一个项目有几百个源文件，并且每个源文件都在不同的目录，我们把每个源文件都这样一个个的写出来，不知道要写到什么时候呢。是否有办法能一次获取目录中的所有cpp文件，并保存在一个变量中，在需要指定源文件的场合直接使用这个变量，这样就简单很多了。cmake中当然有这个方法，它提供了两种方式来实现这个需求。第一种方式是使用 aux_source_directory。它接受一个目录，将指定目录中的所有源文件以list的形式放入到指定变量中，使用它可以将之前的cmake文件改写成下列形式cmake_minimum_required(VERSION 3.15) set(CMAKE_CXX_STANDARD 11) project(test) set(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/bin) aux_source_directory(${PROJECT_SOURCE_DIR}/src SOURCES) include_directories(${PROJECT_SOURCE_DIR}/include) add_executable(hello ${SOURCES})这里我们遍历src目录中的所有源文件，将结果放入到变量SOURCES中。最后在add_executable中将这个结果传入，作为源文件参与最后的编译。第二种方式是可以使用file函数，它能遍历指定目录中的指定文件，并且将结果返回到对应参数中，它的使用方式如下file(<GLOB|GLOB_RECURSE> <variable> [LIST_DIRECTORIES])第一个参数是 GLOB 或者是 GLOB_RECURSE。后者表示递归遍历所有子目录中的文件。第二个参数是变量，最后会将遍历的结果放入到这个变量中。第三个参数是一个可选的，它表示筛选条件，可以填入多个条件。我们可以将上面的aux_source_directories 替换成 file，写成如下形式file(GLOB_RECURSE SOURCES ${PROJECT_SOURCE_DIR}/src/*.cpp)编译静态库和动态库我们再来修改一下这个工程。我们将四则运算的操作独立出来编译为一个静态库，然后在另一个工程中链接这个库并调用这些函数。这个时候可以这么组织工程，在上一个工程的基础上删除main.cpp 就可以了。编译静态库可以使用 add_library 操作符，它用来生成库文件。它可以编译动态库或者静态库。第一个参数是库的名称，最终会生成一个名称为 libname.a 或者 libname.so 的文件，其中name是我们指定的第一个参数；第二个参数是STATIC 或者 SHARED 分别是编译静态库和动态库。第三个参数是编译时需要参与便于的代码源文件。 所以我们的CMakeLists.txt 文件可以这样写cmake_minimum_required(VERSION 3.15) set(CMAKE_CXX_STANDARD 11) project(test) set(LIBRARY_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/bin) file(GLOB_RECURSE SOURCES ${PROJECT_SOURCE_DIR}/src/*.cpp) include_directories(${PROJECT_SOURCE_DIR}/include) # 编译动态库 # add_library(mylib SHARED ${SOURCES}) # 编译静态库 add_library(mylib STATIC ${SOURCES})上面的配置中，使用 LIBRARY_OUTPUT_PATH 来指定库文件生成的路径，最终会在bin目录下生成一个名为 libmylib.so 或者 libmylib.a 的库文件链接静态库和动态库上面我们编译生成了静态库和动态库，该如何在工程中引用它们呢？引用动态库或者静态库可以使用 target_link_libraries。它可以链接静态库或者动态库。在指定要链接的库名称为name 之后，它默认会优先从用户指定的位置查找名为 libname.a 或者 libname.so 的库，如果用户未指定位置或者在指定位置未找到对应的库，那么它会到系统库中查找，都找不到则会报错。我们可以通过 link_directories 来指定库文件的路径，下面是一个示例cmake_minimum_required(VERSION 3.15) set(CMAKE_CXX_STANDARD 11) project(test) include_directories(${PROJECT_SOURCE_DIR}/include) set(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/bin) link_directories(${PROJECT_SOURCE_DIR}/lib) add_executable(hello ${PROJECT_SOURCE_DIR}/main.cpp) target_link_libraries(hello mylib )target_link_library 需要放到 add_executable 或者 add_library 之后，它的第一个参数就是我们在 add_executable 或者 add_library 中给定的生成程序的名称。添加编译宏一般来说，在代码中对于debug版本会额外的输出一些日志信息用于调试，或者根据不同版本来调整某个数据结构的定义，例如#ifdef X64 typedef unsigned long long ULONG_PTR #else typedef unsigned long ULONG_PTRVS 中可以通过预处理器来指定编译时的宏，而GCC 可以通过-D 来指定宏。cmake中也类似，它可以通过 add_compile_definies 来指定宏。它传入的参数于GCC定义宏类似，以-D开头后面跟宏的名称，例如要定义名为 _DEBUG 的宏，可以写成 -D_DEBUG。定义宏后面还可以使用 = 来指定宏的值。下面是一个具体的例子#include <stdio.h> int main (int argc, char *argv[]) { #ifdef _DEBUG printf("this is debug version\n"); #endif printf("the app version is %s\n", VERSION); return 0; }cmake_minimum_required(VERSION 3.15) set(CMAKE_CXX_STANDARD 11) project(test) set(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/bin) add_compile_definitions( -D_DEBUG -DVERSION="1.0.1") add_executable(hello ${PROJECT_SOURCE_DIR}/main.cpp)多个工程嵌套一般在项目中，可能有多个子项目，例如一个web商场可能有前后端之分。在cmake中项目有子工程的话，将各个子工程放到主工程的子目录下，然后使用 add_subdirectory 将各个子项目连接起来。下面是一个具体的例子. ├── calc │   ├── add.cpp │   ├── CMakeLists.txt │   ├── div.cpp │   ├── mult.cpp │   └── sub.cpp ├── CMakeLists.txt ├── include │   ├── calc.h │   └── sort.h ├── sort │   ├── CMakeLists.txt │   ├── insert_sort.cpp │   └── select_sort.cpp ├── test_calc │   ├── CMakeLists.txt │   └── main.cpp └── test_sort ├── CMakeLists.txt └── main.cpp上述项目有4个子工程，分别是四则运算的calc 、排序算法的 sort。以及对应的测试用例test_calc 和 test_sort。算法编译成静态库，测试工程直接链接对应的静态库。基于以上布局，我们在主工程的 CMakeLists.txt 可以这么写cmake_minimum_required(VERSION 3.15) project(test) # 定义变量 # 静态库生成路径 set(LIBPATH ${PROJECT_SOURCE_DIR}/lib) # 可执行程序的存储目录 set(EXECPATH ${PROJECT_SOURCE_DIR}/bin) # 头文件路径 set(HEADPATH ${PROJECT_SOURCE_DIR}/include) # calc库名称 set(CALCLIB calc) # sort 库名称 set(SORTLIB sort) # 测试程序的名字 set(CALCAPP test_calc) set(SORTAPP test_sort) # 添加子目录 add_subdirectory(sort) add_subdirectory(calc) add_subdirectory(test_calc) add_subdirectory(test_sort)在这个文件我们定义了一些其他工程都会用到的一些配置，例如包含的头文件路径、生成程序的路径。以及项目中包含的子项目。在最外层定义的变量可以直接在子工程的cmake 配置文件中使用。这里有点像派生类可以使用基类定义的变量。在calc 子工程中，可以这么配置cmake_minimum_required(VERSION 3.15) project(calc) # 指定要编译的源文件 aux_source_directory(./ SOURCES) # 指定头文件的路径 include_directories(${HEADPATH}) # 指定生成库的路径 set(LIBRARY_OUTPUT_PATH ${LIBPATH}) # 指定生成库的名称 add_library(${CALCLIB} STATIC ${SOURCES})calc 子工程使用根目录工程中定义的变量指定了生成库的路径、库名称。并且直接定义编译成静态库在test_calc 这个测试程序中，可以这么配置cmake_minimum_required(VERSION 3.15) project(test_calc) # 指定头文件的路径 include_directories(${HEADPATH}) # 指定生成exe的路径 set(EXECUTABLE_OUTPUT_PATH ${EXECPATH}) # 指定库文件的目录 link_directories(${LIBPATH}) # 生成可执行文件名称 add_executable(${CALCAPP} ./main.cpp) target_link_libraries( ${CALCAPP} ${CALCLIB} )在测试工程中使用父工程中定义的变量指定了生成程序的路径以及链接库的路径。其他的工程与上面两个子工程的配置类似，只需要改一些变量。就可以运行了。至此, 已经介绍完了使用cmake配置工程的一些基本配置。我们几乎可以将VS 中的项目配置一比一的使用上述内容使用cmake复刻一遍。至于跨平台的配置，无外乎是一些常见的标志判断，根据条件设置变量即可。后续如果我还有好的cmake使用实践也会分享出来。