用C ++设计API [英] Designing an API in C++
问题描述
嗨C ++专家，
我正在开发一个带有C ++ API的软件产品。
我关心的是如何设计API以便API的未来版本
将与使用旧API的应用程序二进制兼容
版本。
例如，假设一个客户应用程序调用API的第1版。我是
开发版本2，它有更多的公共方法和变量。如何使用新的API
版本确保旧应用程序正常工作，而不强迫客户重新编译应用程序？
API应该可以在Windows + Unix上运行，所以我不能用COM来解决这个问题。
欢迎任何想法。
Sruli Ganor
Hi C++ gurus,
I''m developing a software product with a C++ API.
My concern is how to design the API so that future versions of the API
will be binary compatible with applications that use the older API
version.
E.g., suppose a customer application calls version 1 of the API. I
develop version 2, which has more public methods and variables. How can
I make sure that the old application works properly with the new API
version, without forcing the customer to recompile the appl?
The API should work on Windows + Unix, so I cannot use COM to resolve
this problem.
Any ideas would be welcome.
Sruli Ganor
推荐答案
" Sruli" < sr **** @ hotmail.comwrote in message
news：11 ********************** @ i42g2000cwa.googlegr oups.com ...
：我正在开发一个带有C ++ API的软件产品。
：我关心的是如何设计API以便将来的版本API
：将与使用旧版API的应用程序二进制兼容
：版本。
：
：例如，假设客户应用程序调用API的版本1。我
：开发版本2，它有更多的公共方法和变量。怎么能
：我确保旧的应用程序可以正常使用新的API
：版本，而不强迫客户重新编译应用程序？
：
：API应该适用于Windows + Unix，所以我不能用COM来解决
：这个问题。
C ++语言在源代码级别明确指定，
但是目标代码完全取决于实现。
一个问题是类布局可能会改变发布你的库的
发布。
另一个是在某些平台上（特别是x86），一些
编译器不使用相同的ABI（例如实现和布局
的虚函数，名称修改，异常等）
[= Borland C ++和VC ++的不兼容]。
最后但并非最不重要的是，几乎在每个平台上，不同的编译器
（甚至是相同开发环境的连续版本）
使用的实现类布局中不同的C ++标准库
：所以除非使用完全相同的工具链，否则你不能在你的bd中使用std :: string或任何容器/迭代器
界面。
因此，如果您以二进制形式分发您的图书馆，
准备迎接严峻挑战......
极少数（大型）C ++库以二进制形式分发。
着名的BeOS是一个值得注意的例外。但是要控制
平台（定义ABI和库）。然而它必须使用特殊的
技巧来允许未来的扩展（例如添加虚拟
未使用的虚拟函数来解决脆弱基类的问题
问题）。
在我以前的工作中，我正在为触觉设备开发高级接口库
（ www.xitact.com）。虽然用C ++开发的所有东西都是b $ b，但我已经推动提供一个纯C接口
（在#ifdef __cplusplus extern" C" {#endif etc.
实现内部转换的不透明对象句柄
到要转发调用的类实例
a try ... catch（...）子句）。
这绝对是正确的选择。
最初，我们提供了源代码形式的C ++界面，
作为我们的C-interface接口DLL的薄包装器。
但我们的经验证实，不同的客户/开发人员
在任何情况下都希望提供他们自己的包装器<我们的库周围有
，无论如何都会在我们自己的C ++类中封装我们的接口
。
所以他们最终会直接进入C api级别。
如果你真的想提供一个C ++接口并以二进制形式分发你的库
只有表格，准备为每个想要使用它的顾客重新编译你的图书馆。
我不想朝这个方向前进。 br />
作为一个潜在客户，我不会容忍这样的水平
的供应商依赖...
我希望这有助于，Ivan
-
http ：//ivan.vecerina.com/contact/？subject = NG_POST < - 电子邮件联系表格
"Sruli" <sr****@hotmail.comwrote in message
news:11**********************@i42g2000cwa.googlegr oups.com...
: I''m developing a software product with a C++ API.
: My concern is how to design the API so that future versions of the API
: will be binary compatible with applications that use the older API
: version.
:
: E.g., suppose a customer application calls version 1 of the API. I
: develop version 2, which has more public methods and variables. How can
: I make sure that the old application works properly with the new API
: version, without forcing the customer to recompile the appl?
:
: The API should work on Windows + Unix, so I cannot use COM to resolve
: this problem.
The C++ language is well specified at the source code level,
but the object code is totally up to the implementation.
One issue is that class layout could change from release to
release of your libraries.
Another one is that on some platforms (notably x86), some
compilers do not use the same ABI (e.g. implementation and layout
of virtual functions, name mangling, exceptions, etc)
[ =incompatibility of Borland C++ and VC++ ].
Last but not least, on almost every platform, different compilers
(and even consecutive releases of the same development environment)
use implementations of the C++ standard library that differ
in class layout: so unless the exact same tool chain is used,
you cannot use std::string or any container/iterator in your
interface.
So if you distribute your library in binary form,
prepare for a serious challenge...
Very few (large) C++ libraries are distributed in binary form.
The famed BeOS is a notable exception. But Be controlled the
platform (defined ABI and library). Yet it had to use special
tricks to allow for future extensions (such as adding dummy
unused virtual functions to work around the Fragile Base Class
issue).
In my previous job I was developing high-level interface libraries
for haptic devices (www.xitact.com). Although everything was
developed in C++, I have pushed for providing a pure C interface
( within #ifdef __cplusplus extern "C" { #endif etc.
Implement opaque object handles that are internally converted
to a class instance to which calls are forwarded within
a try...catch(...) clause ).
This definitely was the right choice.
Initially, we did provide a C++ interface in source code form,
as a thin wrapper over our C-called interface DLL.
But our experience confirmed that different customers/developers
all wanted in any case to provide their own kind of wrapper
around our library, and would be encapsulating our interface
within their own C++ class in any case.
So they would end up going straight to the C api level.
If you really want to provide a C++ interface AND distribute
your library in binary form only, be prepared to re-compile
your library for every customer who will want to use it.
I wouldn''t want to head in this direction.
And as a potential customer, I wouldn''t tolerate such a level
of vendor-dependence either...
I hope this helps, Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Sruli写道：
Sruli wrote:
你好C ++大师，
我正在开发一个带有C ++ API的软件产品。
我关心的是如何设计API，以便API的未来版本与使用旧版API
版本的应用程序二进制兼容。 />
例如，假设客户应用程序调用API的版本1。我是
开发版本2，它有更多的公共方法和变量。怎么能
我确保旧的应用程序与新的API
版本正常工作，而不强迫客户重新编译appl？
Hi C++ gurus,
I''m developing a software product with a C++ API.
My concern is how to design the API so that future versions of the API
will be binary compatible with applications that use the older API
version.
E.g., suppose a customer application calls version 1 of the API. I
develop version 2, which has more public methods and variables. How can
I make sure that the old application works properly with the new API
version, without forcing the customer to recompile the appl?
提供新界面和旧界面。
by providing both, a new interface and the old one.
API应该可以在Windows + Unix上运行，所以我不能用COM来解决这个问题。
任何想法都会受到欢迎。
The API should work on Windows + Unix, so I cannot use COM to resolve
this problem.
Any ideas would be welcome.
根据我的经验，C ++界面的好处
（例如自动内存管理和C ++异常错误
条件）
远远超重
C ++界面的问题。
在UNIX上，您可以将产品与C ++编译器一起交付
使用
（例如gnu-c ++）。
在Windows上，您可以声称与Visual C ++ VersionX兼容。
in my experience the benefits of a C++ interface
(e.g. automatic memory management and C++ exceptions for error
conditions)
far outweight
the problems with a C++ interface.
On UNIX you can deliver your product together with the C++ compiler
used
(e.g. gnu-c++).
On Windows you can claim compatibility with Visual C++ VersionX.
Peter写道：
Peter wrote:
在Windows上，您可以声称与Visual C ++ VersionX兼容。
On Windows you can claim compatibility with Visual C++ VersionX.
谢谢。什么是Visual C ++ VersionX？
Sruli
Thanks. What is Visual C++ VersionX?
Sruli
这篇关于用C ++设计API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
