标头和宏之间的对应关系 [英] Correspondence between headers and macros
问题描述
我的理解是，当你写一个图书馆
然后标题应该是格式
#ifndef macro_corresponding_to_the_library
#define macro_corresponding_to_the_library
..
.. ...定义......
..
#endif
这样可以防止库中的对象多次定义
，以防标题多次包含
。假设我正确地得到了
我的问题是是否有一些
约定连接标题的名称
与名称宏。如果没有广泛的惯例
存在吗？你有什么建议吗？
给出一个头名的宏名？
Spiros Bousbouras
My understanding is that when you write a library
then the header should be of the form
#ifndef macro_corresponding_to_the_library
#define macro_corresponding_to_the_library
..
.. ...definitions...
..
#endif
This prevents the objects in the library to be
defined more than once in case the header gets
included more than once. Assuming that I got that
correctly my question is whether there is some
convention which connects the name of the header
with the name of the macro. If no widespread convention
exists do you have any suggestions about a rule which
gives a macro name from a header name ?
Spiros Bousbouras
推荐答案
sp *** *@gmail.com 写道：
sp****@gmail.com writes:
我的理解是当你写一个库
然后标题应该是表格
#ifndef macro_corresponding_to_the_library
#define macro_corresponding_to_the_library
。
。 ......定义......
。
#endif
这可以防止库中的对象
定义不止一次，以防标题包含多次b / b
。
My understanding is that when you write a library
then the header should be of the form
#ifndef macro_corresponding_to_the_library
#define macro_corresponding_to_the_library
.
. ...definitions...
.
#endif
This prevents the objects in the library to be
defined more than once in case the header gets
included more than once.
对象的多个定义不是要解决的问题。
你可以把extern int x;多次进入翻译单元
如你所愿，效果是一样的。 （事实上，这不是一个
定义;它只是一个声明。）
问题是实体的多个定义可能只是每个翻译单位定义一次
;例如，结构。
Multiple definitions of objects aren''t the problem being solved.
You can put "extern int x;" into a translation unit as many times
as you like and the effect is the same. (This is not, in fact, a
definition; it''s merely a declaration.)
The problem is multiple definitions of entities that may only be
defined once per translation unit; for example, structures.
假设我得到了正确的问题，我的问题是否是
是连接标题名称的一些约定用
宏的名称。如果不存在普遍的约定，那么你有什么建议可以从一个标题名称中给出宏名称
吗？
Assuming that I got that correctly my question is whether there
is some convention which connects the name of the header with
the name of the macro. If no widespread convention exists do
you have any suggestions about a rule which gives a macro name
from a header name ?
没有普遍接受的约定。我要做的是
在
问题中使用库保留的名称空间中的宏名称。例如，如果您的库名为foolib，那么
所有声明的名称都以foolib_开头，那么您可以使用foolib_h来使用foolib_h。或FOOLIB_H或FOOLIB_H。作为宏名称。
-
调试的次数是首先编写代码的两倍。
因此，如果你尽可能巧妙地编写代码，你是，根据定义，b $ b不够聪明，不能调试它。
--Brian Kernighan
There is no universally accepted convention. What I would do is
to use a macro name from a name space reserved by the library in
question. For example, if your library is named foolib, so that
all of its declared names start with "foolib_", then you could
use "foolib_h" or "FOOLIB_H" as the macro name.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
sp****@gmail.com 写道：
我的理解是，当你写一个库
时，标题应该是格式
#ifndef macro_corresponding_to_the_library
#define macro_corresponding_to_the_library
My understanding is that when you write a library
then the header should be of the form
#ifndef macro_corresponding_to_the_library
#define macro_corresponding_to_the_library
macro_corresponding_to_the_header会更好。
不一定是一对一的对应关系标题和库之间的
。 （考虑与标准库相关的
不同标题的数量，例如
。）
`macro_corresponding_to_the_header'' would be better.
There is not necessarily a one-to-one correspondence
between headers and "libraries." (Consider the number of
different headers associated with the Standard library,
for example.)
。
。 ......定义......
。
#endif
这可以防止库中的对象
定义不止一次，以防标题包含多次b / b
。假设我正确地得到了
我的问题是是否有一些
约定连接标题的名称
与名称宏。如果没有广泛的约定
存在，您对规则有什么建议吗？
从标题名称中给出一个宏名称？
.
. ...definitions...
.
#endif
This prevents the objects in the library to be
defined more than once in case the header gets
included more than once. Assuming that I got that
correctly my question is whether there is some
convention which connects the name of the header
with the name of the macro. If no widespread convention
exists do you have any suggestions about a rule which
gives a macro name from a header name ?
标题的名称通常构成宏名称
的一部分。如果标题被称为grizzle.h，则一些
的人使用GRIZZLE_H作为宏名称。不过，这个方案，
有一个缺陷：对于一个名为eyes.h的标题。配方将是/ b $ b建议EYES_H，但以E开头的宏名称和另一个
大写字母可能与< errno.h>冲突。作为替代方案，
我建议使用H_EYES和H_GRIZZLE。
你应该*不*做的一件事就是模仿你在
您的实现附带的标准头文件。他们
通常会包含名称为_TIME_H
或_STDIO_H的包含保护宏，并且很多人都被引诱思考
他们应该使用他们自己的标题的方案相同：_EYES_H
和_GRIZZLE_H。但是领先下划线的原因是
专门用于避免与用户定义的宏发生冲突 -
实现是严格避免名称空间
属于你。该协议的另一面是，你b $ b应该反过来避免实现的名称空间;如果它实现
，实现为它的
自己的目的定义了_GRIZZLE_H，这会弄乱你的头文件，你自己只有
责备。
-
Eric Sosman
es ***** @ acm-dot-org.inva lid
The name of the header usually forms part of the name
of the macro. If the header is called "grizzle.h", some
people use GRIZZLE_H as the macro name. That scheme, though,
has a flaw: for a header called "eyes.h" the recipe would
suggest EYES_H, but macro names starting with E and another
upper-case letter may clash with <errno.h>. As an alternative,
I''d suggest using H_EYES and H_GRIZZLE.
One thing you should *not* do is imitate what you find in
the standard headers that come with your implementation. They
will often have inclusion-guard macros with names like _TIME_H
or _STDIO_H, and many people have been seduced into thinking
they should use the same scheme for their own headers: _EYES_H
and _GRIZZLE_H. But the reason for the leading underscore is
specifically to avoid collisions with user-defined macros --
the implementation is scrupulously avoiding the name space that
belongs to you. The flip side of that agreement is that you
should in turn avoid the implementation''s name space; if it
turns out that the implementation defines _GRIZZLE_H for its
own purposes and this messes up your header file, you have only
yourself to blame.
--
Eric Sosman
es*****@acm-dot-org.invalid
Ben Pfaff写道：
Ben Pfaff wrote:
sp****@gmail.com 写道：
sp****@gmail.com writes:
我的理解是，当你写一个库
然后标题应该是格式
#ifndef macro_corresponding_to_the_library
#define macro_corresponding_to_the_library < br $> b $ b。
。 ......定义......
。
#endif
这可以防止库中的对象
定义不止一次，以防标题包含多次b / b
。
My understanding is that when you write a library
then the header should be of the form
#ifndef macro_corresponding_to_the_library
#define macro_corresponding_to_the_library
.
. ...definitions...
.
#endif
This prevents the objects in the library to be
defined more than once in case the header gets
included more than once.
对象的多个定义不是要解决的问题。
你可以把extern int x;多次进入翻译单元
如你所愿，效果是一样的。 （事实上，这不是一个
定义;它只是一个声明。）
Multiple definitions of objects aren''t the problem being solved.
You can put "extern int x;" into a translation unit as many times
as you like and the effect is the same. (This is not, in fact, a
definition; it''s merely a declaration.)
当然是的;我的意思是声明。但是，即使它们不会影响可执行文件，同一单元中的多个
声明也不会产生警告吗？
Yes , of course ; I meant declarations. But wouldn''t multiple
declarations in the same unit produce warnings even if they
won''t affect the executable ?
问题是实体的多个定义，每个翻译单元可能只定义一次
;例如，结构。
The problem is multiple definitions of entities that may only be
defined once per translation unit; for example, structures.
我没有在我之前的帖子中选择足够的
护理的术语。我使用了对象这个词。但我真的意味着我们可以在C中定义/声明
变量，结构，宏，数据类型
等
所以我提到的技术要点是防止这些
在同一单元中多次定义，对吧？
I didn''t choose the terminology in my previous post with sufficient
care. I used the word "object" but I really meant anything we can be
defined/declared in C ie variables , structures , macros , data types
etc.
So the point of the technique I mentioned is to prevent some of these
to be defined more than once in the same unit , right ?
这篇关于标头和宏之间的对应关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
