外部“C”在库标题中 [英] extern "C" in library header
问题描述
我辩论这是否属于comp.lang.c ++，最后决定它属于这里的
，因为它确实是一个C问题...
假设我有一个非常友好，无害的库，libfoo，
表示声明的单个函数：
int foo_function（int x）;
世界很简单，所有的小动物都很喜欢它的简单。
沿来自邻居的邪恶的crumudgeon
王国说：我的
人无法使用你的图书馆，我们将向你宣战！
希望避免灾难，我们通过添加野兽的纹身来玷污我们美丽的
标题：
#ifdef __cplusplus
externC {
名称空间foo {
#endif
和匹配的结束括号。
几年两个
王国有平安。
有一天，邻国王子的年轻王子
决定： foo :: foo_function（x）有多余的
foo，并且认识到他的王国仍有足够的政治影响力，他宣称所有的实施都是
$ b $ libfoo的b必须提供较少冗余的接口。并且
所以我们辉煌的标题再次毁容并结束
看起来像：
#ifndef FOO_HDR
#define FOO_HDR 1
#ifdef __cplusplus
extern" C" {
namespace foo {
#endif / * __cplusplus * /
int foo_function（int x）;
#ifdef __cplusplus
int function（int x）{return foo_function（x）; }
} / * namespace foo * /
} / * externC * /
#endif / * __cplusplus * /
#endif / * FOO_HDR * /
问题是：
1）鉴于libfoo是一个C库，并且foo.h是一个
C头文件，我发现上面的代码有点
可怕。但是，它确实为C ++程序员提供了一个相当干净的界面。
那里有什么会烧掉我的C代码吗？
2）鉴于最终的#ifdef __cpluplus块
将要为库中的所有内容定义函数
...它是否值得麻烦？
之后，邪恶的王子将获得的唯一东西是
使用b $ b的能力 FOO ::功能"而不是
" foo :: foo_function"。但他的foo命名空间
仍然混乱。我发现
标题中的定义是一个令人发指的kludge，但据我所知，这是一种公认的技术
不远的地方，超出了
水冷却器。你怎么想？
-
William Pursell
I debated whether this belongs in comp.lang.c++, and finally decided
that it belongs here, because it really is a C question...
Suppose I have a perfectly friendly, harmless library, libfoo,
that presents a single function declared:
int foo_function(int x);
The world is simple and all the small creatures rejoice in
its simplicity.
Along comes the evil crumudgeon from the neighboing
kingdom who says: your library is not useable by my
people, and we will declare war on you!
Wishing to avert a catastrophe, we sully our beautiful
header somewhat by adding the tatoo of the beast:
#ifdef __cplusplus
extern "C" {
namespace foo {
#endif
and matching closing braces.
For several years, there is peace in the two
kingdoms.
One day, a young prince of the neighboring kingdom
decides that: foo::foo_function( x ) has redundant
foo, and recognizing that his kingdom still has
enough political clout, he declares that all implementations
of libfoo must provide a less redundant interface. And
so our glorious header is disfigured again and ends
up looking like:
#ifndef FOO_HDR
#define FOO_HDR 1
#ifdef __cplusplus
extern "C" {
namespace foo {
#endif /* __cplusplus */
int foo_function(int x);
#ifdef __cplusplus
int function( int x ) { return foo_function( x ); }
} /* namespace foo */
} /* extern "C" */
#endif /* __cplusplus */
#endif /* FOO_HDR */
The questions are:
1) Given that libfoo is a C library, and that foo.h is a
C header file, I find the above code somewhat
hideous. However, it does seem to provide a
fairly clean interface to the C++ programmer.
Is there anything there that will burn my C code?
2) Given that the final #ifdef __cpluplus block
is going to have to define functions for everything
in the library...is it even worth the hassle? After
all, the only thing the evil prince will gain is
the ability to use" foo::function" instead of
"foo::foo_function". But his foo namespace
is still cluttered. I find the definitions in the
header to be a heinous kludge, but as far as
I can tell, it is an accepted technique in that
not-so-far-away land that lies beyond the
water cooler. What think you?
--
William Pursell
推荐答案
William Pursell说：
< snip>
William Pursell said:
<snip>
>
问题是：
1）鉴于libfoo是一个C库，那个foo.h是一个
C头文件，我发现上面的代码有点
可怕。
>
The questions are:
1) Given that libfoo is a C library, and that foo.h is a
C header file, I find the above code somewhat
hideous.
同样。
Likewise.
但是，它确实提供了一个
相当干净的C ++程序员界面。
However, it does seem to provide a
fairly clean interface to the C++ programmer.
火焰喷射器也是如此。
我自己的首选策略基于以下推理：
1）这是一个C头，所以它只会遵循C规则。
2）如果C ++人想要使用它，太棒了！如果没有，谁在乎呢？
3）如果他们需要在它周围换上另一个标题，那我就好了，但是我没有改变这个一个。
< snip>
So would a flamethrower.
My own preferred strategy is based on the following reasoning:
1) this is a C header, so it''ll follow C rules, ONLY.
2) if C++ people want to use it, great! If not, who cares?
3) if they need to wrap another header around it, that''s fine
by me, but I ain''t changing this one.
<snip>
我在
标题中找到定义是一个令人发指的污秽物，但据我所知，这是一种公认的技术。
不那么遥远的土地超出了/>
水冷却器。你怎么想？
I find the definitions in the
header to be a heinous kludge, but as far as
I can tell, it is an accepted technique in that
not-so-far-away land that lies beyond the
water cooler. What think you?
我认为C ++人员有很好的技巧可以处理不需要修改这些库或它们的C />
库。
相关标头。如果他们没有，他们就不会那么擅长代码
如他们所想的那样重复使用。
-
Richard Heathfield< http://www.cpax.org.uk>
电子邮件：-www。 + rjh @
谷歌用户：< http://www.cpax.org.uk/prg/writings/googly.php>
Usenet是一个奇怪的放置" - dmr 1999年7月29日
I think C++ people have perfectly good techniques for dealing with C
libraries that do not involve modifying those libraries or their
associated headers. And if they haven''t, they''re not as good at code
re-use as they fondly imagine.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
2007-06-29，Richard Heathfield< rj*@see.sig.invalidwrote：
On 2007-06-29, Richard Heathfield <rj*@see.sig.invalidwrote:
William Pursell说：
William Pursell said:
>我发现
标题中的定义是一个令人发指的kludge，但就<我可以说，这是一种公认的技术，因为它不是那么遥远的土地，而是在水冷却器之外。你怎么想？
>I find the definitions in the
header to be a heinous kludge, but as far as
I can tell, it is an accepted technique in that
not-so-far-away land that lies beyond the
water cooler. What think you?
我认为C ++人员有很好的技巧可以处理不需要修改这些库或它们的C />
库。
相关标头。如果他们没有，他们就不会像他们喜欢的那样擅长代码
重复使用。
I think C++ people have perfectly good techniques for dealing with C
libraries that do not involve modifying those libraries or their
associated headers. And if they haven''t, they''re not as good at code
re-use as they fondly imagine.
I完全同意，并且围绕C
头文件包装命名空间完全没有意义。更糟糕的是，这是有害的，并且b $ b误导。
在C代码中，该函数将被称为foo_function，无论
什么''命名空间''C ++代码假装它在。如果C ++
代码有名称冲突的问题，那么这个kludge不会
帮助。要么C ++代码还有其他函数叫做$ / b $ b foo_function，C ++编译器已经将它们分解成不同的
命名空间，这样它们就不会发生冲突，或者它有其他的外部命令。 C"函数
真正被称为foo_function，即使假装它们是
也不能在编译时为C ++代码实现，它不会去
可以让它与所有冲突的定义联系起来
of foo_function。
I totally agree, and this wrapping of a ''namespace'' around the C
header file is utterly pointless. Worse than that, it''s harmful and
misleading.
In the C code the function will be called foo_function regardless of
what ''namespace'' the C++ code has pretended that it is in. If the C++
code has a problem with name clashes, then this kludge is not going to
help. Either the C++ code has other functions supposedly called
foo_function which the C++ compiler has mangled into different
namespaces so they don''t clash, or it has other extern "C" functions
which really are called foo_function and even if pretending they are
not can be achieved at compile time for the C++ code, it''s not going
to be possible to get it to link with all the conflicting definitions
of foo_function.
William Pursell< bi ** ********@gmail.com写道：
William Pursell <bi**********@gmail.comwrote:
#ifndef FOO_HDR
#define FOO_HDR 1
#ifdef __cplusplus
externC {
namespace foo {
#endif / * __cplusplus * /
int foo_function（int x）;
#ifdef __cplusplus
int function（int x）{return foo_function（x）; }
} / * namespace foo * /
} / * externC * /
#endif / * __cplusplus * /
#endif / * FOO_HDR * /
#ifndef FOO_HDR
#define FOO_HDR 1
#ifdef __cplusplus
extern "C" {
namespace foo {
#endif /* __cplusplus */
int foo_function(int x);
#ifdef __cplusplus
int function( int x ) { return foo_function( x ); }
} /* namespace foo */
} /* extern "C" */
#endif /* __cplusplus */
#endif /* FOO_HDR */
Bah。
Bah.
问题是：
1）鉴于libfoo是一个C库，而且foo.h是一个
C头文件，我发现上面的代码有点
可怕。
The questions are:
1) Given that libfoo is a C library, and that foo.h is a
C header file, I find the above code somewhat
hideous.
这甚至没有开始描述它。
也许最好的解决方案是拥有两个标题，一个foo.h代表C，
和一个用于c ++的foo.h ++。稍微多一些工作，但可能是值得的。
Richard
That doesn''t even begin to describe it.
Perhaps the best solution would be to have two headers, a foo.h for C,
and a foo.h++ for c++. A slight bit more work, but probably worth it.
Richard
这篇关于外部“C”在库标题中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
