第三届中国 Rust 开发者大会 安全高效的二进制序列化 Daniel Wang @ NEAR Borsh • 运行、编码效率 • 确定性 • 跨平台兼容性 二进制序列化的问题 Binary Object Representation Serializer for Hashing • 字节级别确定性 • 执行速度快 Borsh • 轻量级 • 每一个对象与其二进制表示之间都存在一个双射映射

(printable character) 外， ASCII 还规定了一 类特殊的控制字符 (control character) ： • 0 表示空字符（‘ \0’ ） • 9 表示 Tab 制表符（‘ \t’ ） • 10 表示换行（‘ \n’ ） • 13 表示回车（‘ \r’ ） • 27 表示 ESC 键（‘ \x1b’ ） • 127 表示 DEL 键（‘ \x7f’ ）等 • 0~31 ）强制终止程序，这时常常会看到 一个 ^C 的字样，就是这样出现的。这里我 们的 cat 程序收到 ^C 以后，就直接终止退 出了。 关于控制字符的一个冷知识 • 除此之外，因为 ^D 是“传输终止符”，还可以在控制 台输入 Ctrl+D 来关闭标准输入流，终止正在读取他 的程序。 • 小彭老师常用 Ctrl+D 来快速关闭一个 shell （和输入 exit 命令的效果一样）。 • 以及按 n 个字符作为一个子字 符串，删除后半部分。 “0 结尾字符串”知识点应用举例 • C 语言所谓的字符串类型 char * 实际上就是个首地址指 针，如果让首地址指针向前移动 n 位，那就实现删除前 n 个字符的效果，而不用实际修改数组本身（更高效）。 C 语言转义符 • 常见的转义符： • ‘\n’ 换行符：另起一行（光标移到下一行行首） • ‘\r’ 回车符：光标移到行首（覆盖原来的字符）

long 的大小应该和系统架构位数一样， 32 位系统上就 32 位， 64 位系统上就 64 位。 Windows 认为 long 不论 32 位系统还是 64 位系统都一样应该为 32 位，认为这样安全。 因此我们在编写 C 语言程序时，应该避免使用 long 类型，他会导致你的程序难以跨平台。 除了 long 之外的其他类型则没有区别，可以放心使用。 无符号整数： unsigned 修饰 有符号版本 long unsigned long signed long long unsigned long long 其实 C 语言也有 signed 修饰符，但是因为不加默认就是 signed 的，所以其实没有使用 signed 的必要。 字面常量：通过修饰符来确定 • 在数字后面追加 U 和 L 可以表示不同类型的字面常量，例如： • 32 是 int 类型 • 32L 是 long 类型 • abs(int x); • 因此在输入给他一个浮点类型的 x 时，相当于 • x = (float)abs((int)x) • 所以被 x 被隐式转换（不会产生错误）成了 int 之后才调用 abs ，相当于调用了 x = abs(- 3) 。 fabs 函数：取出浮点的绝对值 • abs 是整数的绝对值函数，而这里我们其实是 需要浮点的绝对值函数，他叫做 fabs ： • double

作为虚函数。然后定义： Numeric *twice(Numeric *t) { return t->multiply(2); } 且不说这样的性能问题，你忍得住寂寞去重复定义好 几个，然后每个运算符都要声明一个纯虚函数吗？ 而且， Float 的乘法应该是 multiply(float) ，你也去 定义好几个重载吗？定义为 multiply(Numeric *) 的话 依然会违背你们的开 - 闭原则：比如 端是不同的类型，怎么处理所有可能类型的排列组合 ？ 不如放弃类和方法的概念，欣然接受全局函数和重载 。 模板函数：定义 • 使用 template • 其中 T 可以变成任意类型。 • 调用时 twice 即可将 T 替换为 int 。 • 注意有的教材上写做： • template • 是完全等价的，只是个人喜好不同。 模板函数：自动推导参数类型 模板函数：自动推导参数类型 • 那这样需要手动写 ， 用起 来还不如重载方便了？ • 别担心， C++ 规定： • 当模板类型参数 T 作为函数参数时，则可 以省略该模板参数。自动根据调用者的参 数判断。 模板函数：特化的重载 • 有时候，一个统一的实现（比如 t * 2 ）满 足不了某些特殊情况。比如 std::string 就 不能用乘法来重复，这时候我们需要用 t +

解构函数是显式的，离开作用域自动销毁，毫不含 糊（有好处也有坏处，对高性能计算而言利大于 弊） 如果没有解构函数，则每个带有返回的分 支都要手动释放所有之前的资源 : RAII ：异常安全（ exception-safe ） C++ 标准保证当异常发生时，会调用已创建对象的解构函数 。 因此 C++ 中没有（也不需要） finally 语句。 如果此处不关闭，则可等 待稍后垃圾回收时关闭。 虽然最后还是关了，但如 果对时序有要求或对性能 show(80) 和 show({80}) 等价。 使用 {} 和 () 调用构造函数，有什么区别？ 1. int(3.14f) 不会出错，但是 int{3.14f} 会出错，因为 {} 是非强制转换。 2. Pig(“ 佩奇” , 3.14f) 不会出错，但是 Pig{“ 佩奇” , 3.14f} 会出错，原因同上，更安全。 3. 可读性： Pig(1, 2) 则 Pig 有可能是个函数， Pig{1 Pig{1, 2} 看起来更明确。 • 其实谷歌在其 Code Style 中也明确提出别再通过 () 调用构造函数，需要类型转换时应该 用： 1. static_cast(3.14f) 而不是 int(3.14f) 2. reinterpret_cast(0xb8000) 而不是 (void *)0xb8000 • 更加明确用的哪一种类型转换（ cast ），从而避免一些像是

BENCHMARK_MAIN 自动生成了一个 main 函数 ，从而生成一个可执行文件供你运行。运行后会得到测试 的结果打印在终端上。 命令行参数 他还接受一些命令行参数来控制测试的输出格式为 csv 等等，你可以调用 --help 查看更多用法。 CMake 中使用： find_package CMake 中使用：作为子模块 这个什么“勾勾”公司非要默认开启 tests ，导致需要去寻找 googletest 完毕后才去认领下一个任务，从而即使每个任务 工作量不一也能自动适应。 • 这种技术又称为线程池（ thread pool ），避免了 线程需要保存上下文的开销。但是需要我们管理 一个任务队列，而且要是线程安全的队列。 struct Task { int x0, y0; int nx, ny; }; std::queue q; 1 2 3 4 解决 3 ：每个线程一个任务队 加数据。 • 这就导致前半段的元素的地址被改变，从而导致 之前保存的指针和迭代器失效。 reserve 预留足够的 capacity • 如果预先知道 size 最后会是 n ，则可以 调用 reserve(n) 预分配一段大小为 n 的 内存，从而 capacity 一开始就等于 n 。 这样 push_back 就不需要动态扩容，从 而避免了元素被移动造成指针和迭代器失 效。

chrono::steady_clock::time_point 等 • 时间段类型： chrono::milliseconds ， chrono::seconds ， chrono::minutes 等 • 方便的运算符重载：时间点 + 时间段 = 时间点，时间点 - 时间点 = 时间段 • auto t0 = chrono::steady_clock::now(); 值函数，但是提供了移动构造 / 赋值函数。 • 因此，当 t1 所在的函数退出时，就会调用 std::thread 的解构函数，这会销毁 t1 线程 。 • 所以， download 函数才会出师未捷身先死 ——还没开始执行他的线程就被销毁了。 解构函数不再销毁线程： t1.detach() • 解决方案：调用成员函数 detach() 分离该 线程——意味着线程的生命周期不再由当 前 程还是有点麻烦，我们可以自定义一个类 ThreadPool ，并用他创建一个全局变量， 其解构函数会在 main 退出后自动调用。 std::jthread ：符合 RAII 思想，解构时自动 join() • C++20 引入了 std::jthread 类，和 std::thread 不同在于：他的解构函数里会 自动调用 join() 函数，从而保证 pool 解 构时会自动等待全部线程执行完毕。 小彭老师快乐吐槽时间

map 容器 by 彭于斌（ @archibate ） 我负责监督你鞋习 ! 我负责监督你鞋习 ! 本期看点： 用方括号 [ ] 取出 map 元素居然是错误的！ 能不能在遍历的同时删除元素？安全吗？ emplace ， emplace_hint ， try_emplace 的区别？ 课程安排 1. vector 容器初体验 & 迭代器入门 (BV1qF411T7sd) 2. 你所不知道的 在写入时又和多数语言的 [] 行为一致了。 • 这时 [] 自动默默创建的特性反而是个优点了，如果用了 at() 反而会在插入新键值时莫名 其妙报错。此外 [] 默默创建以后把值初始化为 0 的特性，由于调用者是 = val 赋值，所 以初始化也没用了，反正马上会写入 val 。 浅谈这种精分设计的原因 • 总结，要符合你熟悉的 Python 的 [] 行为，在 C++ 中要根据不同情况选择不同的方法访 __getitem__ 。 • 也就是说 Python 的 [] 其实是调用了两个不同的运算符重载： • m[key] = val 实际上是 m.__setitem__(key, val) 。 • val = m[key] 实际上是 val = m.__getitem__(key) 。 • C++ 的 [] 就不论读取还是写入都是同一个运算符重载，他只是返回引用，无法区分你是读是写： • value_type

性能优化 之 无分支编程 Branchless Programming by 彭于斌（ @archibate ） 两种代码写法：分支 vs 三目运算符 两种使用方式：排序 vs 不排序 测试结果（均为 gcc -O3 ） 测试结果可视化 图表比较：分支 vs 无分支 分支 无分支 0 0.01 0.02 0.03 耗时（越低越好） 乱序 有序 • 传统的分支方法实现的 或者更满足“对称强迫症”的： • (cond) * a + !(cond) * b // 方法 2 • 还有一种“摆烂”的做法： • (cond ? a : b) // 方法 3 • 三目运算符通常会变成和 if-else 一样的分 支，同样会生成条件跳转指令，理应一样 低效。但是有时候编译器会检测到，可以 帮你自动优化成无分支版本的。 “ 妙用加减乘”进行无分支优化的通用公式 • __declspec(noinline) 才能编译。 不同写法的性能测试 可以看到不论是哪个优化级别，“妙用加减乘”的效果都是碾压 ifelse 的。 “ 摆大烂”的效果和 ifelse 几乎一样，也就是说根本没用，三目运算符还是生成了 低效的跳转指令，自己不上进，还指望编译器来救你？你还不如坐等天上掉馅饼。 从汇编角度分析（ -O0 ） 从汇编角度分析（ -O3 ） 因为 clamp 用了两次分支， if-else-if-else

等各种选项。然后通过 project 命令初始 化了根项目。 • 随后通过 add_subdirectory 把两个子项 目 pybmain 和 biology 添加进来（顺序 无关紧要），这会调用 pybmain/CMakeLists.txt 和 biology/CMakeLists.txt 。 三、子项目的 CMakeLists.txt 配置 • 子项目的 CMakeLists • 因为子项目的 CMakeLists.txt 里指定的路径都是相对路径 ，所以这里指定 include 实际上是：根 /biology/include 。 • 注意我们用了 PUBLIC 修饰符，这是为了让链接 biology 的 pybmain 也能够共享 根 /biology/include 这个头文件搜 索路径。 五、子项目的源文件 • 这里我们给 biology 批量添加了 是他里面并没有解引用 Animal ，只有源文件 Carer.cpp 解引用了 Animal 。 • 那么这个头文件是不需要导入 Animal.h 的，只需要一个前置声明 struct Animal ，只有实际调用了 Animal 成员函数的源文件需要导入 Animal.h 。 • 好处：加快编译速度，防止循环引用。 十一、以项目名为名字空间（ namsepace ），避免符号冲突 • 在声明和定义外面