在 github 上我们能找到 protobuf 的 最新发布版本

在发布的压缩包中，我们只需要关注 protobuf-cpp-version.zip/tar.gz。有时 protobuf-version-win32.zip 也会让人疑惑，我们到底需不需要这个文件呢？让我们看一下其中的 readme.txt

This package contains a precompiled binary version of the protocol buffer compiler (protoc). This binary is intended for users who want to use Protocol Buffers in languages other than C++ but do NOT want to compile protoc themselves.

简单说，是给 C++ 开发者之外的码农用的。

但是，If you intend to use the included well known types，我们还是需要下载后者的。毕竟前者中 .proto 原型混杂在了大量的头文件中，而这里的原型文件一目了然。

二进制

在解析文件服务器上的历史 k 线时，碰到了比较特殊的问题：

强调：安装 IDE 时不要变更默认路径！否则，使用 vcpkg 磨难重重，vcpkg issue#12488。我安装 Language English 就失败了，后面也就没尝试。

从 visual studio 2015 的“选项”跳转到的中文网站，选择英文语言包下载到的其实是中文语言包，需要更换到对应的英文网站下载才是正确的。仍旧需要使用默认安装路径！

网速要好，偶尔也需要翻墙。如果使用系统自带的 powershell 碰到下载失败、下载慢，且版本陈旧。建议下载 powershell core 试一试，可能会有惊喜。 在 Windows 终端中设置代理 解决问题：$Env:https_proxy="http://127.0.0.1:10809"

使用 vcpkg 安装库后，如果较长时间未更新，再次更新时可能报错：

1
2
3
4
5
6

PS F:\vcpkg> .\vcpkg.exe update
Using local portfile versions. To update the local portfiles, use `git pull`.
Error: while loading boost-signals:
The port directory (F:\vcpkg\ports\boost-signals) does not exist
Error: failed to load port from F:\vcpkg\ports\boost-signals
Note: Updating vcpkg by rerunning bootstrap-vcpkg may resolve this failure.

此时按照提示重新执行多次 bootstrap-vcpkg 也是无效的，我们需要清理掉过时的库：

1
2
3
4
5
6
7
8

PS F:\vcpkg> .\vcpkg.exe list boost-signals
boost-signals2:x86-windows-static-md               1.71.0           Boost signals2 module
boost-signals:x86-windows                          1.68.0           Boost signals module
PS F:\vcpkg> .\vcpkg.exe remove boost-signals:x86-windows
The following packages will be removed:
    boost-signals:x86-windows
Removing package boost-signals:x86-windows...
Removing package boost-signals:x86-windows... done

之后就使用正常了：

1
2
3
4
5
6
7
8

PS F:\vcpkg> .\vcpkg.exe update
Using local portfile versions. To update the local portfiles, use `git pull`.
The following packages differ from their port versions:
    abseil:x86-windows               2020-03-03-4 -> 2020-09-23#3
    abseil:x86-windows-static-md     2020-03-03-4 -> 2020-09-23#3
    asio:x86-windows                 1.12.2 -> 1.18.0
    asio:x86-windows-static-md       1.12.2-2 -> 1.18.0
    boost-accumulators:x86-windows-static-md 1.71.0 -> 1.75.0

除特别备注，全部摘自 vcpkg: A C++ package manager for Windows, Linux and MacOS。此章节类似读书（博客）笔记。

streambuf

中文版 https://zh.cppreference.com/w/cpp/io/basic_streambuf，偶有误差，可参考英文版本纠正。

英文版 https://en.cppreference.com/w/cpp/io/basic_streambuf

类 basic_streambuf 控制字符序列的输入与输出。它包含下列内容并提供到它们的访问：

1. 受控字符序列（The controlled character sequence），也称作 buffer，可包括：input sequence (also called get area) 用于缓冲输入操作；以及 output sequence (also called put area) 用于缓冲输出操作。

2. 关联字符序列，又称作源（对于输入）或池（对于输出）。它可以是通过 OS API 访问的实体（文件、 TCP 接头、串行端口、其他字符设备），或者可以是能转译成字符源或池的对象（ std::vector 、数组、字符串字面量）

受控制序列中的字符表示和编码可以异于关联序列中的字符表示，该情况下典型地用 std::codecvt 本地环境进行转换。常见的例子是通过 std::wfstream 对象访问 UTF-8 （或其他多字节编码）文件：受控制字符序列由 wchar_t 字符组成，但关联序列由字节组成。

automake 系列工具友好性的确不咋地，而且只限于 *inux 平台。跨平台还是 cmake 为佳，也有越来越多的项目在使用 cmake，比如 google 的 gRPC，比如 zlib 也支持 cmake。

如果只是说要编译三方库为自己所用，一般来说不需要掌握怎么编写 CMakeLists.txt；只有当自己的项目需要用 cmake 管理、组织编译时才需要弄懂 CMakeLists.txt 中的“语言”怎么编写。

使用 cmake

mkdir build && cd build && cmake .. && cmake --build . --target install

cmake --build . 在 linux 下等价于 make，在 windows 下等同于 msvc 生成解决方案

之前专门整理过 C++ 怎么写单例类，平日项目中涉及的场景大多简单，使用最基本的实现就完全能够应付过来。但是，还是有些复杂的场景需要考虑。

相互引用的单例们

也就是 singletonA、singletonB 两者的构造相互调用。

使用常用的局部静态变量方式（lazy_result_loop.cpp），也是懒汉模式一种：相互依赖初始化，死循环，阻塞

1
2

Object_2B_1::Object_2B_1() this:[00BFC14C] data_2b_1_ [1].
Object_2B_2::Object_2B_2() this:[00BFC154] data_2b_2_ [2].

使用全局静态变量方式（hungry_result_different.cpp），饿汗模式：不会死循环，但奇葩在 Debug、Release 模式执行结果不一致

代码摘抄自 BOOST 的 Singleton 模版详解，以上就是“2B 实现有问题”。虽然作者自述“BOOST 的实现如何规避问题”，但在 msvc2015 中实测其代码并未解决问题，依旧是阻塞结果。

自从看了蒋鑫的《Git权威指南》之后就开始使用Git Submodule功能，团队也都熟悉了怎么使用，多个子系统（模块）都能及时更新到最新的公共资源，把使用的过程以及经验和容易遇到的问题分享给大家。

Git Submodule功能刚刚开始学习可能觉得有点怪异，所以本教程把每一步的操作的命令和结果都用代码的形式展现给大家，以便更好的理解。

对于公共资源各种程序员的处理方式：

每个公司的系统都会有一套统一的系统风格，或者针对某一个大客户的多个系统风格保持统一，而且如果风格改动后要同步到多个系统中；这样的需求几乎每个开发人员都遇到，下面看看各个层次的程序员怎么处理：

假如对于系统的风格需要几个目录：css、images、js。

普通程序员，把最新版本的代码逐个复制到每个项目中，如果有N个项目，那就是要复制N x 3次；如果漏掉了某个文件夹没有复制…@（&#@#。

文艺程序员，使用Git Submodule功能，执行：git submodule update，然后冲一杯咖啡悠哉的享受着。

在使用 git 版本仓库时，难免会出现默认配置不符合我们需要的地方。尤其是在 windows 上使用 git 时，不如意的地方就会更频繁的出现。这时需要我们自己手动微调 git 的默认配置，汇总如下：

别名

经常输入 git status 查看库当前状态，如果终端环境不支持 tab 自动补全，频繁输入 status 完整单词就会变得很繁琐，考验耐心；即便支持自动补全，git status 和 git stash 也是前缀相同。这时我们可以考虑 使用别名：

1
2
3
4

$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status

Configure.ac 文件解析

原理：Autoconf 是用来产生 “configure” 文档的工具。“configure” 是一个 shell script，它可以自动设定原始程序以符合各种不同平台上 Unix 系统的特性，并且根据系统参数及环境产生合适的 Makefile 文档或是 C 的标头档 (header file)，让原始程序可以很方便地在这些不同的平台上被编译出来。Autoconf 会读取 configure.in configure.ac 档然后产生 “configure” 这个 shell script。

configure.in configure.ac 文档的内容是一连串 GNU m4 的巨集，这些巨集经过 autoconf 处理后会变成检查系统特征的 shell script。configure.in configure.ac 内巨集的顺序并没有特别的规定，但是每一个 configure.in configure.ac 档必须在所有巨集前加入 AC_INIT 巨集，然後在所有巨集的最后面加上 AC_OUTPUT 巨集。

一般先用 autoscan 这个工具扫描原始文件以产生一个 configure.scan 文件，再对 configure.scan 作些修改，从而生成 configure.in configure.ac 文件。

执行脚本 ./configure

configure：它能根据不同的系统，产生不同的 Makefile，从而使我们的程序具有可移植性。它还有一些参数：

这篇帖子很棒！我从百度文库中下载了 此教程，因为未做深度的考证，所以也不知原作者是谁，但在此谢谢作者。以下是作者原文，略有删改，本人有修改部分都已做出备注。

使用过开源 C/C++ 项目的同学们都知道，标准的编译过程已经变成了简单的三部曲：configure/make/make install, 使用起来很方便，不像平时自己写代码，要手写一堆复杂的 Makefile，而且换个编译环境，Makefile 还需要修改（Eclipse 也是这样）。

这么好的东东当然要拿来用了，但 GNU 的 Autotool 系列博大精深，工具数量又多，涉及的语言也多，要是自己从头看到尾，黄花菜都凉了，项目估计早就结束了；上网搜样例倒是有一大堆，但都是“hello world”的样例，离真正完成大型项目的目标还差得远。

没有办法，对照网上的样例，再找几个开源的源码，然后参考各种 Autotools 的手册，花了 2 天时间，终于完成了一个基本可用的 Autotools。为了避免其他 XDJM 也浪费时间，因此将过程总结下来，就算是新年礼物，送给大家！！