如何设计一个C / C ++库是许多客户端语言使用吗？ [英] How to design a C / C++ library to be usable in many client languages?

问题描述

我打算code应在平台范围广泛是可用通过大量的人库。我有什么要考虑合适的设计呢？为了使这个质疑更具体地，有四个子问题末

I'm planning to code a library that should be usable by a large number of people in on a wide spectrum of platforms. What do I have to consider to design it right? To make this questions more specific, there are four "subquestions" at the end.

考虑到所有已知的要求和细节，我得出的结论是用C或C ++库是要走的路。我觉得我的图书馆的主要用途将是写在 C，C ++和Java SE ，但我也可以想到的原因，从 Java ME的，PHP，.NET使用它的程序，目标C，Python和Ruby，bash的scrips，等等... 也许我不能针对所有的人，但如果可能的话，我会做到这一点。

Considering all the known requirements and details, I concluded that a library written in C or C++ was the way to go. I think the primary usage of my library will be in programs written in C, C++ and Java SE, but I can also think of reasons to use it from Java ME, PHP, .NET, Objective C, Python, Ruby, bash scrips, etc... Maybe I cannot target all of them, but if it's possible, I'll do it.

这将是多大来形容我在这里库的完整的目的，但也有一些方面可能是对这个问题很重要：

It would be to much to describe the full purpose of my library here, but there are some aspects that might be important to this question:

• 库本身会开始时小，但肯定会增长到非常复杂的，所以它不是维持几个版本并行的选项。


• 最复杂的将图书馆藏在里面，虽然


• 图书馆将建设用于大量内的对象图。库的一些客户端只会有兴趣的特定对象的特定属性，而其它客户端必须以某种方式遍历对象图


• 客户可能会改变对象和库必须通知其


• 库可能改变的对象，并在客户端必须它们通知，如果它已经具有手柄到该对象


• 库必须是多线程的，因为它会维护网络连接到其它多个主机


• 虽然一些请求到库中，可以同步处理，其中许多人会花很长时间，且必须在后台进行处理，并通知客户端上的成功（或失败）

的当然，答案是欢迎不管他们解决我的具体要求，或者如果他们回答这个问题在关系到更广泛的受众一般的方式！的

因此​​，这里是我的一些假设和结论，这是我聚集在过去几个月的：

So here are some of my assumptions and conclusions, which I gathered in the past months:

• 在内部，我可以使用任何我想要的，例如C ++运算符重载，多继承，模板元编程...只要有一个便携式编译器处理它（认为GCC / G ++）


• 但我的接口必须是干净的C接口，不涉及名称重整


• 另外，我觉得我的界面应该只包含的功能，基本/基本数据类型（也许指针）作为参数传递和返回值


• 如果我使用指针，我想我应该只用它们来它们传回库，而不是直接对引用的内存操作


• 对于C ++应用程序的使用，我也可以提供一个面向对象的接口（这也是容易出现名称重整，所以应用程序必须使用相同的编译器，或者包括以源代码形式库）


• 这也为真正使用在C＃？


• 对于在Java SE / Java EE的使用状况，Java本地接口（JNI）适用。我有一些关于它的基本知识，但我一定要仔细检查它。


• 并非所有的客户端语言处理多线程很好，所以应该有一个单独的线程交谈客户端


• 有关Java ME的使用，有没有这样的东西作为JNI，但我可能会与嵌套VM
去

• 对于的bash脚本的使用，都必须有一个命令行界面的可执行文件


• 对于其他客户端语言，我不知道


• 对于大多数客户端语言，这将是不错的一种用该语言编写的适配器接口。我认为有工具来自动生成这对Java和其他一些人


• 对于面向对象的语言，有可能创建一个面向对象的适配器，它隐藏了接口库是基于功能的事实 - 但我不知道它值得努力

• 这可能与管理的努力，还是只是太多的便携性？


• 有没有关于这种设计标准？
什么好书/网站

• 是我的任何假设错了吗？


• 该开源库是值得我们学习他们的设计/接口/烃源学？


• 元：这个问题是相当长的，你看到了什么办法把它分割成几个小的？的（如果您回复此，做到这一点为注释，而不是作为一个答案）的

• is this possible with manageable effort, or is it just too much portability?
• are there any good books / websites about this kind of design criteria?
• are any of my assumptions wrong?
• which open source libraries are worth studying to learn from their design / interface / souce?
• meta: This question is rather long, do you see any way to split it into several smaller ones? (If you reply to this, do it as a comment, not as an answer)

推荐答案

晴正确的。直程序接口是最好的。 （这是不完全同C BTW（**），但足够接近）

Mostly correct. Straight procedural interface is the best. (which is not entirely the same as C btw(**), but close enough)

I接口的DLL了很多（*），开源和商业的，所以这里是我从日常实践记住一些要点，注意，这些是研究推荐更多的领域，而不是基本的真理：

I interface DLLs a lot(*), both open source and commercial, so here are some points that I remember from daily practice, note that these are more recommended areas to research, and not cardinal truths:

• 当心装修和类似次要的重整计划，特别是如果你使用MS编译器。最引人注目的是stdcall调用约定有时会导致装修产生的VB的缘故（装饰的东西，如@ 6后，函数符号名）


• 并非所有的编译器实际上可以布置各种结构：
  
  
  
  • 所以要避免过度使用工会。
  
  
  • 避免bitpacking
  
  
  • 和preferably包的记录。虽然速度较慢，至少所有的编译器可以访问AFAIK打包记录
  
  
  
  
  • 宏很难自动转换，由于其untypeness。避免它们，使用功能
  
  
  • 定义不同的类型为每个指针类型，也不要在函数的声明使用复合类型（的xtype **）。
  
  
  • 按照使用之前定义的口号尽可能的，这将避免转换头重新排列，如果他们在一般的语言在使用之前需要定义用户，并使其更容易一通解析器给他们翻译。或者，如果他们需要的信息环境自动翻译。
  
  

  （**）
  这是因为什么C表示二进制仍然依赖于所使用的C编译器，特别是如果没有真正的通用系​​统ABI。想想一样的东西：

  (**) This is because what "C" means binary is still dependant on the used C compiler, specially if there is no real universal system ABI. Think of stuff like:

  
  
  • C对一些二进制格式添加下划线preFIX（a.out的，COFF？）
  
  
  • 有时不同的C编译器都对如何处理按值传递小的结构做不同的意见。据官方统计，他们不应该支持它在所有据我所知，但大多数做的。
  
  
  • 结构的包装有时变化，因为这样做调用约定的详细信息（如跳绳
     整数寄存器与否如果一个参数是在FPU寄存器可注册）
  
  

  =====自动转换头====

  ===== automated header conversions ====

  虽然我不知道那SWIG很好，我知道并使用一些特定的Delphi工具头（h2pas，达思/ headconv等）。

  While I don't know SWIG that well, I know and use some delphi specific header tools( h2pas, Darth/headconv etc).

  不过，我从来没有在全自动模式下使用它们，因为更多的时候则不是输出很烂。评论更改线路或被剥离，和格式不保留。

  However I never use them in fully automatic mode, since more often then not the output sucks. Comments change line or are stripped, and formatting is not retained.

  我平时做一个小脚本（Pascal中，但是你可以使用体面的字符串支持任何东西）一个分割头了起来，然后尝试的工具上相对同质的部分（如只结构，或只定义等）。

  I usually make a small script (in Pascal, but you can use anything with decent string support) that splits a header up, and then try a tool on relatively homogeneous parts (e.g. only structures, or only defines etc).

  然后我检查，如果我喜欢的自动转换输出，要么和使用它，或尝试做具体转换自己。因为它是一个子集（例如仅结构）它往往比制作一个完整的报头转换器的方式更容易。当然，这取决于一点我的目标是什么。 （不错，读标题或快速和肮脏的）。在每一步我可能会做一些替换（使用sed或编辑器）。

  Then I check if I like the automated conversion output, and either use it, or try to make a specific converter myself. Since it is for a subset (like only structures) it is often way easier than making a complete header converter. Of course it depends a bit what my target is. (nice, readable headers or quick and dirty). At each step I might do a few substitutions (with sed or an editor).

  最复杂的方案我为WINAPI commctrl和ActiveX / COMCTL头。在那里，我结合IDL和C头（IDL的接口，这是一群在C，C头的其余部分不可分析宏），并设法让宏类型的约80％（按propogating在SendMessage函数的类型转换宏回到宏观声明，以合理的（WPARAM，LPARAM，LRESULT）默认）

  The most complicated scheme I did for Winapi commctrl and ActiveX/comctl headers. There I combined IDL and the C header (IDL for the interfaces, which are a bunch of unparsable macros in C, the C header for the rest), and managed to get the macros typed for about 80% (by propogating the typecasts in sendmessage macros back to the macro declaration, with reasonable (wparam,lparam,lresult) defaults)

  半自动化的方式的缺点是声明的顺序是不同的（例如，第一常量，那么结构则函数声明），有时使得维护一种痛苦。因此，我始终保持原有的页眉/ SDK和比较。

  The semi automated way has the disadvantage that the order of declarations is different (e.g. first constants, then structures then function declarations), which sometimes makes maintenance a pain. I therefore always keep the original headers/sdk to compare with.

  绝地WINAPI转换项目可能有更多的信息，他们翻译大约一半的窗口标题德尔福，因而具有巨大的经验。

  The Jedi winapi conversion project might have more info, they translated about half of the windows headers to Delp and thus have enormous experience.

  这篇关于如何设计一个C / C ++库是许多客户端语言使用吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！