C 不再是一种编程语言( 四 ) _编程语言

my_rad_symbol ，但针对 my_rad_symbol_v1 链接。
然后当你决定实际上应该使用int64_t时，你可以把int64_t my_rad_symbol(int64_t) 作为my_rad_symbol_v2，但保留旧的定义作为my_rad_symbol_v1 。任何针对较新版本头文件进行编译的人都会高兴地使用v2符号，而针对旧版本进行编译的人则继续使用v1!
但是你仍然有一个兼容性的问题：任何用新头文件编译的人都不能与库的旧版本进行链接，库的V1版本根本没有V2符号！因此，如果你想获得热门的新功能，你就要接受与旧系统的不兼容。
不过这并不是什么大问题，它只是让平台供应商感到难过，因为没有人能够立即使用他们花了这么多时间做的东西。你不得不推出一个闪亮的新功能，然后让大家等待它变得足够普遍和成熟。但为了人们愿意依赖它并中断对旧平台的支持（或者愿意为它实施动态检查和回退）时，你必须坐等几年。
如果你真的想让人们立即升级，那就要谈论向前兼容的问题。这让旧版本的东西以某种方式与他们没有概念的新功能一起工作。

文章插图
在不破坏ABI的情况下更改类型
那除了可以改变一个函数的签名，还可以改变类型布局吗？Aria表示，这取决于你是如何暴露类型的。
C真正奇妙的一个特点是，它可以让你区分一个已知布局的类型和一个未知布局的类型。如果你只在C头文件中前向声明一个类型，那么任何与之交互的用户代码都不被“允许”知道该类型的布局，并且必须一直在指针后面不透明地处理它。
所以你可以做一个像MyRadType* make_val和use_val(MyRadType*)的API，然后使用同样的符号版本技巧来暴露make_val_v1和 use_val_v1符号，任何时候你想改变这个布局，你就在所有与该类型交互的东西上增加版本。类似地，你在MyRadTypeV1、MyRadTypeV2和一些类型定义中保留了一些，以确保人们使用“正确”的类型。这样就可以在不同的版本之间改变类型的布局。
如果多个东西建立在你的库之上，然后开始用不透明类型相互交谈，坏事就会发生：

lib1: 制作一个API，接受MyRadType*并调用use_val
lib2：调用 make_val并将结果传递给lib1

如果lib1和lib2针对库的不同版本进行了编译，那么make_val_v1就会被输入到use_val_v2中！你有两个选择来处理这个问题：
1.说这是被禁止的，责备那些无论如何都要这么做的人，然后伤心
2.以一种向前兼容的方式设计MyRadType，这样混合就可以了
常见的前向兼容技巧包括：

保留未使用的字段供未来版本使用
MyRadType的所有版本都有一个共同的前缀，可以让你“检查”你所使用的版本
拥有自定大小的字段，以便旧版本可以“跳过”新的部分

文章插图

案例研究：MINIDUMP_HANDLE_DATA微软是这种向前兼容的大师，甚至可以实现在架构之间保持布局兼容。Aria最近正在处理的一个例子是Minidumpapiset.h中的
MINIDUMP_HANDLE_DATA_STREAM 。
这个API描述了一个有版本的值列表。该列表以这种类型开始：
typedef struct _MINIDUMP_HANDLE_DATA_STREAM { ULONG32 SizeOfHeader; ULONG32 SizeOfDescriptor; ULONG32 NumberOfDescriptors; ULONG32 Reserved;} MINIDUMP_HANDLE_DATA_STREAM, *PMINIDUMP_HANDLE_DATA_STREAM;其中：