一个 C 接口设计的问题
C 语言在本质上，参数传递都是值传递。不像 Pascal 和 C++ 可以传引用。这一点，使得 C 语言可以保持简单的设计，但另一方面也颇为人诟病。
因为性能问题，指针不得不被引入。可以说，用 C 语言实现的软件，其实现的 Bug 90% 以上都来至于指针，应该是没有夸大了。当然设计引起的问题或许更为关键一些，那些于指针无关。
纠结于性能问题上，层次比较低。可 C 语言就是一个活跃在较低层次的语言，一旦你选择用它，就不得不关心性能问题。反过来，把 C 模仿成更高级的语言，倒是有点画蛇添足了。好了，让我们来看个实际的涉及参数传递的相关问题，用 C 语言该如何设计。
最近同事在做一个类似 Protocol Buffers 的东西。这个东西做好并不容易，设计上尤为困难。其中的设计难点：设计一个合适的 DSL (领域专用语言) 我们讨论过很久，也分析了好几天，但今天不打算谈了。拣个小东西说：当我们把一个二进制结构化数据块解析出来，传递到 C 语言中，让 C 语言可以方便的访问数据结构时，接口如何设计？
这个问题在目标语言不是 C 而是更高级的语言（尤其是有 gc 机制的语言）时，都不是问题。可 C 语言本身是没有对象概念的。
C 语言有结构，但是不具备描述动态长度的能力；没有字符串，只有定长的字符数组；甚至没有多维数组，只有一维数组的数组。
C 函数的参数及返回值可以是结构，但在接口设计中，或许是因为值传递，以及考虑 ABI 的简洁性的关系，常常使用结构指针。返回结构指针往往有生命期管理的苦恼。即使到了 C++ 里，允许返回结果/对象了，可所谓返回值优化也是件相当让人困扰的事情（如果你打算完全放弃了解语言的细节，无视细微处的性能问题。那么，为什么不考虑使用 Java 或是 Python ，无论什么都比选择 C++ 强）。
对于返回一组复杂数据，通常的办法有些什么？
最常用的方法是，调用者分配空间，传递给处理函数。由处理函数反向填写结构内容。这样的好处是，调用者可以选择把空间分配在栈上还是堆上。一点小提示：在语法上，C 语言允许你把一个数组当成指针来传递。所以你可以定义一个长度为 1 的结构数组类型。用起来好看一些。具体见 标准库中的 setjmp 的定义 。不过作为我个人的理念来说，不太主张在 C 语言设计的软件中，为了减少几次键盘输入，而使用过多的语言特性。
这个方式的缺点是，你很难让调用者定义不定的数据结构。尤其是在结构里还有对别的结构的引用。
跟这个相似的是接收字符串。最典型的例子是标准库中的 fgets ，提供一个接收缓冲区的地址指针，和一个缓冲区大小。（注：gets 则是一个失败的设计）同样在 Windows 的 API 中，也随处可见这样的例子。
第二，就是由函数自己分配内存，交给调用者去释放。大家只需要约定内存管理的接口即可。标准库中的 strdup 就是这样做的，同样的还有 readline 库中的 readline 。C 语言统一使用 malloc 管理内存，不像 C++ 提供了更灵活（更难控制，更容易出问题？）的 new 操作符重载。所以，给出这个约定并不会增添太多的麻烦。btw, 由于微软 VC 的 CRT 对 malloc 等实现的过于糟糕，导致很多 Windows 的软件自行实现内存管理器。或者在库中开放自定义内存管理器注入的接口。这其实有点越俎代庖了。gcc 提供的 CRT 里， malloc 性能就相当不错了。
缺点呢？内存只能从堆上分配；而且增加了内存泄露的隐患；设计角度上讲，也不太干净。对于复杂数据结构，这个方法也无能为力。C 语言里并没有所谓析构函数的说法。
作为对第二点的一种补充方案，用的人就凤毛麟角了。那就是给你的系统加入 gc 。实际上，就是约定另一种内存管理方法。我们的项目部分模块在用，效果还不错。 gc 库已经开源，请参考这里 。如果信不过这套东西，可以考虑 COM 的机制：增减引用。COM 旨在建立一种对象模型，可惜 C 语言中没有对象的概念，在 C 的层面使用 COM ，痛苦了一些。对于粒度比较小的东西，性能也将是问题。
第三种，用的人也比较多。就是在函数内部开一块静态空间，用于数据返回。返回的指针指向的数据的生命期可以保证到下次调用同一函数之前。静态空间可以声明在数据段里，也可以在程序初始化时从堆上分配出来，这样利于在空间不够的时候扩展。至于这块静态空间什么时候释放的问题，不用太操心。即使不去释放它们也不用内疚。操作系统会帮你回收的，还会比你干的更出色。C 是为了实现 UNIX 而诞生，而 UNIX 的哲学就是，编写简单的程序专心干好自己的事，让更高层次的程序（通常是 shell 或动态语言）去组合它们，让操作系统去管理它们。在 Windows 上，Unix 编程哲学未必有用，但大原则没错的。
这个方案有另外一个问题，就是函数不可重入，且有线程安全问题。重入问题可以想办法避免。线程安全可以用 TLS 解决。老实说，我个人不看好在 C 语言中使用多线程解决问题。多线程也是违背 Unix 哲学的。如果你有几件事情需要协调起来做，使用多进程；如果你有几百件事情需要同时来做，考虑换个思路，玩玩 Erlang 啥的。
回到今天我们面临的问题。用一种 DSL 来描述一个数据结构（比 C 的结构表达能力更强的），然后生成对应语言的解析库。如果目标语言是 C 的话，我们生成的代码如何返回对 C 程序员友好的结构化数据呢？
这让我想到了 MySQL 的 C 语言接口。很多初学 C++ 的程序员，很喜欢把那些 C 接口“封装”成“漂亮”的 C++ 接口。直接返回 vector 套 map 的多层模板实例。不知道有多少人干过？前几年我带实习生的时候反正见过不少。如果同学你现在醒悟了，明白这是件巨傻X 的事情，那么握握手，我们有共同理念；否则（C++ 封装以后不是很“酷”吗？），我们暂时没有共同语言了。
我不是想说 MySQL 的 C 接口设计的很好，不过是中规中矩。只是 C++ 不是 C ，C 也不是 C++ 。（话说，上面提到的 C++ 封装，我也不认为是正确的使用 C++ ）反复提及 C++ ，是因为，我发现今天很大比例的 C 程序员其实是从 C++ 开始启蒙的，而不是相反。把 C++ 当成 C 用的危害其实比不上把 C 当成 C++ 用。前者不过是把汽车开到自行车的速度，至少不怕摔跤了，跑起来还能安全点；而后者，非要把自行车踩到高速公路中间，迟早非撞死不可。
最方便 C 程序使用的莫过于传入一个结构指针，让库去解析数据，填写这个结构了。
但是，如果结构里有字符串、不定长数组（通常会根据前面解析出来的数据决定后面的长度，对于 C 的编程技巧来说，允许把结构体的最后一个数组的长度设为 0 ，假设成不定长的，从而减少一次间接的指针引用。但是对于结构中有多个不定长数组则无法使用这个技巧。）等等的话，就很难避免指针了。
数据中一旦出现指针（间接引用别的数据），就有内存管理问题。
最开始，考虑过一个很 C++ 的方案，传入一个内存管理器。这种设计在 STL 里就有。所有 STL 的容器都可以指定一个 allocator ，供灵活的管理内存。前几年我倒是认为这是个相当巧妙的东西。没有细想，自定义分配器最终有多大的意义？自定义内存管理器，很大程度上是因为效率因素引起的。但性能问题永远不是根本问题。制作软件是为了达到特定的目的，而软件开发的问题更多的是是解决复杂度问题。往往复杂度带来的性能问题更加严重。然后为了解决复杂度带来的性能问题去引入更高的复杂度，出现恶性循环的可能性非常之大。
即使我们传入的内存管理器（或是直接使用 CRT 里的 malloc，但这样就没可能利用堆栈分配空间了），还会面临新问题，如何回收结构中间接引用的数据。引入析构函数指针？OMG 。
后来，我们设想使用一个内部静态空间，所有的解析结果都分配在内部，自我管理。这些空间还可以复用。大部分解析结果也就是临时用用，这样做很方便。而且调用者不用太关心数据的生命期。
但是，一旦调用者需要把结果（一个复杂结构）保存一段时间的话，他就遇到困难。
当然，也可能不是困难。当我们面对这个设计难点时，都应该向上考虑一层，究竟这是一个问题吗？我们需要这么用吗？
调用者可以自己遍历这个数据结构，把他需要的数据，以自己的方式复制出来，组织起来。他们需要的是数据，而不是对数据结构完全的拷贝。
仔细考虑过以后，我们还是发现，保留完整的数据结构是有意义的。不像 C++ ，C 没有对象赋值操作符重载这种语法糖，我也不喜欢用宏去模拟一个出来。增加一个拷贝函数指针其实和增添一个析构函数一样，对 C 来说，不那么漂亮。（当然，同时增加了开发量，我们需要编写更多的代码自动生成器）
最终，我们采用了由调用者传入缓冲区指针的方案。要求解析器生成的数据结构放在一块连续的内存空间上。这样，调用者就可以把指针直接定义成最终方便访问的结构或联合。但是提供更充裕的内存空间，存放那些内部引用的数据（比如字符串）。
因为结果数据区是由调用者提供，就不存在数据复制移动引起的指针调整问题（调用者可以自己先分配好）。
最后一个问题是，如何让调用者估算数据接收区的大小呢？
很多 Windows API 可以通过两次调用来完成，第一次空调用计算需要的缓冲区大小，第二次真的去填写数据。根据实际需求分析过之后，我认为在我们这个模块的应用上，这样做是多余的。我们尽可以让用户随便给一个估算大小去处理数据，一旦空间不够，返回错误信息。让用户自己扩大缓冲区，重新调用一次即可。
btw, 不断重试是我们最终认可的最 KISS 的方案。一开始，我们认为让处理程序自己分配内存，并自己使用 realloc 更好。后来发现，完全是多余的设计。因为，解析二进制流是 O(1) 的操作，不比估算长度慢；而往往调用者都能正确估算接收区应有的长度，即使简单的每次两倍的方法扩展接收区大小，也不会浪费多少处理时间。即使他们需要精确分配结果需要的内存块，尽可以用一个足够大的公用缓冲区接收，然后得到长度信息，重新在特定内存上重来一次即可。
写累了。想表达的也表达完了。今天到此为止。 :D
ps. 前几天写了一篇关于 一种对汉字更环保的 Unicode 编码方案 ，我昨晚花了两小时写了个简单的 C 实现。可以把 UTF-8 或 UTF-16 转换到我自己定义的暂且命名为 UTF-C 的编码上，也可以转回来。代码用的行数比预想的要多一些，因为我低估了 UTF-8 的处理复杂度（其实也不复杂啦）。
Comments
开年以来读到的第一篇雄文，如饮烈酒，甘冽有劲。
Posted by:
寒流 | (24)
February 27, 2011 01:28 AM
strdup是posix的, 不是c库.呵呵
Posted by:
cc | (23)
August 6, 2010 10:16 PM
哈哈，我们有共同点语言，我大胆地猜测，风云大哥一定更喜欢使用写codegen来解决语言的不足，而不是去依赖某一语言的特性。
Posted by:
artizc | (22)
February 14, 2009 03:00 PM
方法三稍微修改，函数内部静态空间每线程一个，与当前线程(ID)捆绑。实现上以线程ID为key，在数组或HashMap中存放缓存，实现颇为简单，性能几乎丝毫不损，也可解决文中大部分问题，唯是不可重入。不过正如云风所说，这个问题可能不是问题。
Posted by:
rich | (21)
January 30, 2009 11:04 AM
C 语言标准并没有特别限制返回值不能是什么，所以 C 是允许返回struct 作为一种返回复杂数据的方案的。
不知道被以前看过的哪本书误导，我觉得返回 struct 是 C++ 对 C 的一个扩展。（其实不是）
感谢指出这个错误的朋友，我今天仔细核对了 ISO C90 和 ISO C99 标准。:D
Posted by:![[TypeKey Profile Page]](http://img.it610.com/image/product/d3de99e9e7684e7182d1d9fd778f5424.gif)
| (20)
Cloud
January 10, 2009 08:01 PM
您的语言表达能力有待提高啊。。。
Posted by:
Avin | (19)
January 9, 2009 01:40 PM
"这让我想到了 MySQL 的 C 语言接口。很多初学 C++ 的程序员，很喜欢把那些 C 接口“封装”成“漂亮”的 C++ 接口。直接返回 vector 套 map 的多层模板实例。不知道有多少人干过？前几年我带实习生的时候反正见过不少。如果同学你现在醒悟了，明白这是件巨傻X 的事情，那么握握手，我们有共同理念；否则（C++ 封装以后不是很“酷”吗？），我们暂时没有共同语言了。"
呵呵，我也这样干过。不过，没办法，谁叫咱，那时候刚学会
c++,不管什么东西，都要用我的c++这把小斧头试试啊。
Posted by:
Anonymous | (18)
January 9, 2009 01:14 PM
windows api的调用历来就是这么做的
Posted by:
Anonymous | (17)
January 8, 2009 05:05 PM
为什么说C函数不能返回结构？
Posted by:
Anonymous | (16)
January 8, 2009 03:42 PM
为什么不看看xdr? sun rpc中的数据序列化方式，如果嫌它在线程安全上问题太多，那么看看cdr?C++和java都在用它。corba的idl和sun rpc的xdr就是两个很好的用DSL定义数据然后交给C语言去解析的例子。我觉得你所讨论的这些，在它们的实现上全有答案。
至于allocator，我只在loki中看见它为小对象设计过，专用于小于64bits的小对象的分配。我觉得这方面是花力未必讨好的事情。有时间可以做点别的优化。哦，可以借其做内存泄露的调试器。
至于数据接收区的大小，我觉得stl的stringstream以及string/vector这些都做的很好，根据需求自动增长，还可以让程序员可以灵活的预留空间。但是可惜没有realloc。不知道你的应用具体是什么情形，如果每次都是delete/new而没有realloc,对于性能影响大不。
Posted by:
snnn | (15)
January 8, 2009 02:49 PM
感觉就是在说fgets嘛
Posted by:
zii | (14)
January 8, 2009 12:09 PM
这篇文章提了一个问题：如何用C语言接收被调用函数返回的数据块？
答案是：调用者分配内存，然后传指针给调用函数。被调用者往里面填数据。
简单的说就是：去超市买东西得自备购物袋。
Posted by:
D.K | (13)
January 8, 2009 10:19 AM
当初我以为指针的数值等于指针指向的地址
后来才发现这两是不等的。
我到现在还是没搞清楚这两者的关系。
只是 知道 指针的数值的地址包含有个指针头数据才到指针真正的数据的地址。
有没有语法或函数得到一个指针指向数据的长度？
Posted by:
dvaknheo | (12)
January 7, 2009 11:50 PM
感觉写得很混乱，看得不是很明白，说的是对2进制数据的描述？
bioware的很多游戏文件都是2进制描述的，比如.tlk，从博德1开始发展到现在也没淘汰，可以描述一段对话的文本（字符串），配音文件（字符串），时间轴（浮点），颜色什么的，实现也简单，像元数据，先用一个数据结构描述数据结构的结构，然后就是按字节依次填充了
Posted by:
black | (11)
January 7, 2009 08:13 PM
我们公司的模块间数据接口多数是这种类似fread的方案。不过看RADVISON的代码就喜欢传分配器了。
GLib就有点用C写C++的感觉。
Posted by:
zelor | (10)
January 7, 2009 06:26 PM
传分配器也可以"要求解析器生成的数据结构放在一块连续的内存空间上"啊，只不过，真的有点怪，明明传了个分配器，却又约定只能调用一次-_-!或者传一个类似于realloc的分配器？
Posted by:
天堂的隔壁 | (9)
January 7, 2009 05:25 PM
呵呵，最终的解决办法 省心啊， 时间真的很宝贵，省出的时间可以泡泡妞，灌灌水， 这才叫生活
Posted by:
lbaby | (8)
January 7, 2009 02:35 PM
pool 是一个内部解决方案，能不暴露出来就不暴露出来。否则，就需要记住两个东西：1. 结构的地址, 2. pool . 并且要记住两者的关系。
如果要用的话，最好和别的部分正交化。比如，先创建后 pool 传递 buffer 指针进去。
至于 pool 的伸展能力，在这里不是必须的。文中已有讲述。遵循能减则减的原则，就可以去掉了。
其实在堆上还是在栈上的问题，即使传分配器，也是都可以兼顾到的 ：） 只要愿意弄点奇技淫巧的话。
传分配器的大问题是，复杂的数据结构是多次分配的，而最终需要一次释放。这限制了分配器的设计（必须设计成 pool 那种，而不能是 C 标准的 malloc ）
Posted by:![[TypeKey Profile Page]](http://img.it610.com/image/product/d3de99e9e7684e7182d1d9fd778f5424.gif)
| (7)
Cloud
January 7, 2009 01:43 PM
虽然内存管理器等方案也不算坏，但从KISS上说，传内存确实用起来最简单，也灵活。（注意云风多次强调，内存可以在堆里分，也可以在栈上分，似乎要达到这个目地传内存就是唯一的方法了）
Posted by:
天堂的隔壁 | (6)
January 7, 2009 12:45 PM
哈哈，新年好，特别谢谢上个星期云风大哥帮我抽中的豆浆机，豆浆很好喝，呵呵。
平时也一直在用c语言，说些我的看法吧：
1、c是用来做一些底层和性能要求较高的事情，如果不是很注重性能的话，没必要用它。
2、c是可以传结构体的。c中对于不定的结构体，可以用void指针。
4、对于像nginx这类代码，可以借鉴一下它里面的pool的概念。也就是对于不同的生存期的对象定义不同的pool，在对象开始时，分配一定的内存，在对象存活时，可以从这个pool中分配内存，不够的话，扩大这个pool。在对象消亡时，释放这个对象的pool。pool底层的实现其实都是malloc来做的。不过它的特定环境是session这类有特定生存期的对象，与程序的原有设计关系很大，如果是通用的内存分配，像这类东西就没法做到了。
Posted by:
yaoweibin | (5)
January 7, 2009 10:43 AM
GLib很多模块都是传构造和析构函数指针进去，或者至少传析构指针
Posted by:
Anonymous | (4)
January 7, 2009 09:10 AM
至于说的引入析构函数指针的问题，一般情况下，内存都由内存分配器管理，不同生命期的对象使用不同的管理器，如果只牵涉的内存的话，我觉得要注册析构的情况是很少的
Posted by:
exile | (3)
January 7, 2009 01:40 AM
我觉得传入一个内存管理器的方式挺好的啊，比如像nginx这样的内存管理，有点类似于Apache的apr_pool，但更适合一般的应用，除了性能的提升，更重要的是使用起来更简单，最终统一释放，也不容易产生内存泄露。
Posted by:
exile | (2)
January 7, 2009 01:28 AM
不懂？学习！
Posted by:
xinghang | (1)
January 7, 2009 12:23 AM