统一 ezio Buffer 的算术类型读写接口

ezio Buffer 一开始的时候只为 read, write 和 peek 提供了从 int8_tint64_t 的函数重载,如果需要处理 unsigned integers,那么就需要自己额外做 static_cast

ezio 的主要客户藏心同学早前抱怨过这个问题,并且同时建议我加上对 float/double 的浮点数支持。

对于这个建议我一开始是抵触的:

  • 自己 cast 又不是不能用,额外加重载支持三个操作工作量都要翻一番呢
  • 浮点数的 binary serialization 本来就是很难跨平台的,不是每个环境都(虽然大部分)要求使用 IEEE 754 spec。如果真的需要直接把浮点数存到网络包里,自己直接操作 underlying binary layout 不就好了…

于是藏心同学一开始开的 issue 我一直没理他,于是最后他自己关掉了…

等到我自己动手写一个 socks4a proxy 的时候我发现,自己 cast 真的是…太蛋疼了…而且代码看上去还非常丑,大面积的 static_cast 制造了相当一部分内容噪音。那会儿我大概有点理解藏心同学的内心感受。

于是我思考良久,打算改造 Buffer 的这部分接口,以支持绝大多数 integer types,顺带也增加入 floating piont types 的支持,这样 read, write, peek 就基本支持了绝大多数 arithmetic types。

通过直接增加重载是我极力避免的,因为除了接口签名外,大部分实现几乎是一样的,不外乎:

  • 如果是单字节,直接写/读操作
  • 如果是多字节,首先字节序转换,然后做写/读操作
  • 如果是浮点数,首先按照对应字节大小的整数类型解释内存,然后参考普通整数的处理

于是自然而然的想到直接将函数做成 function templates 来增强语义。

Read More

Monthly Read Posts in Mar 2019

Networking

The State of Browser Caching, Revisited

Read More

socks4a 协议代理

对于网络编程学习而言,尝试实现一个 proxy 是一个很好的途径。因为一个 proxy 对于 clients 来说是 server,对 remote servers 来说又是 client,一下就覆盖到了网络编程的两个大块。

同时,需要管理/协调两侧的连接对如何正确的处理网络连接的关闭也是一个挑战。

Read More

推荐 Google API Design Guide

Google API Design Guide

基本上 可以看作是 Google 开放的 API 设计指南。

大体上,Google 对外公开的 API 设计有如下几个特点:

Read More

Monthly Read Posts in Feb 2019

Network

Designing Headers for HTTP Compression

看起来是 HTTP/2 的 header compression 使用建议


How to Think About HTTP Status Codes

HTTP status codes 使用建议。

适合结合 Rest API design 相关文章一起食用。

Programming Languages

论golang Timer Reset方法使用的正确姿势

golang 这破 timer 坑真多


Guaranteed Copy Elision

C++ 17 Guaranteed copy elision explained.

Read More

在 Linux 上使用深信服 VPN

因为公司使用 Windows 和 MacOS 的人最多,因此导致两个后果:

  1. 连接公司内网需要使用的深信服 VPN 基本只支持 Windows 和 MacOS
  2. 后端 golang 大仓代码基本只能在 MacOS 或者 Linux 上提交和调试

求一下交集可以发现,在贵司使用 Linux 作为开发平台的同学应该很难过。很不幸的是,我刚好属于那种在 Linux (虚拟机里跑 Mint) 上写后端服务的人。

公司买的深信服的 VPN 服务,那个客户端虽然官方宣称支持 ubuntu,但是事实是压根不能用,连接成功后一旦有数据包就自动断开。

官方论坛有人反映过类似的问题,得到的回答千篇一律都是推荐使用 Windows 和 MacOS。

然而让我使用屎一样的 MacOS 是不可能的;让我在自己的主力台式机的 Windows 上装深信服的客户端也是不可能的。

Read More

C++ 工程依赖管理新方向:CMake & Git

本文内容中提及的 CMake 均指提倡 target-based properties 的 modern cmake,而非史前版本的 legacy cmake。

The Right Way: 源码依赖

对于 C++ 工程而言,只要 ABI 的问题还存在,源码依赖就是最稳妥最普适最可靠的依赖引入方式;即使这些引入的源码在构建中会单独编译成(动/静态)库。

同时,GitHub 成为开源文化社区的标杆后,获取实现了某一功能的第三方库的源代码的难度大大降低。

因此个人倾向上:只要允许,都应该以特定版本的源码引入的方式去依赖一个第三方库。

事实上,Google Facebook 这些大厂内部实行的 monorepo 也是源码依赖的一种实现方式,因为某个工程需要的依赖源码都可以一并获取到。

在使用 CMake 作为构建系统的工程体系下,要以源码依赖的方式添加一个子工程只需要使用 add_subdirectory() 添加目标工程的顶层目录(根 CMakeLists.txt 所在的目录)。

Git Submodule: 一次不完美的尝试

我的个人项目 KBase 和 ezio,在此之前都是通过 git submodule 的方式引入自己需要的依赖源代码,然后通过

  • Visual Studio 子工程添加到解决方案(Windows 平台)
  • CMake add_subdirectory() 建联(*nix 平台)

依赖的版本管理直接复用 submodule 提供的特性。

Read More