领先的下划线 [英] leading underscore

问题描述

第17.4.3.1.2节规定，以下划线

开头的每个名称都保留给实现，以用作全局

命名空间中的名称。


究竟是什么定义了实现？


它是否只是由编译器的内部名称处理狭义定义？

或者它还包括编译器附带的库吗？

它是否包含OS库作为实现的一部分？


我''开发一些便携式泄漏跟踪代码，并且对于大多数函数来说，我不能在头文件中使用命名空间，因为代码必须能够b / b
编译到C和C ++源文件。


我正在试图确定什么是最好的命名约定

使用，我正在考虑像以下：

_leaktracker61_free

_leaktracker61_realloc

_leaktracker61_DumpAllLeaks

_leaktracker6 1_fopen

_leaktracker61_fclose


在DEBUG模式下编译时，这些函数将在

全局命名空间中，所以我'试图限制名称冲突。


我想知道我是否可以将我的代码视为

实现的扩展，并在那里使用避免名字的主要下划线

碰撞。

Section 17.4.3.1.2 states that each name that begins with an underscore
is reserved to the implementation for use as a name in the global
namespace.

Exactly what defines the implementation?

Is it only narrowly defined by the compiler''s internal name handling?
Or does it also include the library that comes with the compiler?
Does it include the OS library as part of the implementation?

I''m developing some portable leak tracking code, and for most functions
I can''t use namespaces in the header because the code has to be able to
compile to both C and C++ source files.

I''m trying to determine what would be the best naming convention to
use, and I''m considering something like the following:
_leaktracker61_free
_leaktracker61_realloc
_leaktracker61_DumpAllLeaks
_leaktracker61_fopen
_leaktracker61_fclose

When compiled in DEBUG mode, these functions are going to be in the
global namespace, so I''m trying to limit name collision.

I''m wondering if I can consider my code as an extension to the
implementation, and there by use the leading underscore to avoid name
collision.

推荐答案

Axter写道：

Axter wrote:

究竟是什么定义了实现？

它只是由编译器的内部名称处理狭义定义吗？
它还包括随附的库编译器？
它是否包含OS库作为实现的一部分？


是，是，是的。实现几乎所有东西

除了您正在编写的代码之外。


我想知道我是否可以将我的代码视为
实现，并通过使用前导下划线来避免名称
碰撞。

Exactly what defines the implementation?

Is it only narrowly defined by the compiler''s internal name handling?
Or does it also include the library that comes with the compiler?
Does it include the OS library as part of the implementation?
Yes, yes, and yes. The implementation is pretty much everything
other than code YOU are writing.

I''m wondering if I can consider my code as an extension to the
implementation, and there by use the leading underscore to avoid name
collision.

那不可移植。


你最好的选择是不要使用下划线并希望你的

长的独特名字不会与应用程序中的任何一个碰撞

正在测试中。

That wouldn''t be portable.

Your best bet is to NOT use the underscore and hope your
long distinctive names don''t collide with any in the application
under test.

Axter写道：

第17.4.3.1.2节规定每个名称以下划线开头
保留给实现用作全局
命名空间中的名称。

究竟是什么定义了实现？


你是正在阅读标准的人。它是不是定义了

''实现''？

它是否只是由编译器的内部名称处理狭义定义？
或者是它还包括编译器附带的库？


第17条的标题是什么（17.4.3.1.2来自哪个）？

是否包含操作系统库作为实施？


在第17条开头是不是已经说过了？

我正在开发一些便携式泄漏跟踪代码，对于大多数人来说函数
我不能在标题中使用名称空间，因为代码必须能够编译成C和C ++源文件。

我正在尝试确定什么是最好的命名约定
使用，我正在考虑以下内容：
_leaktracker61_free
_leaktracker61_realloc
_leaktracker61_DumpAllLeaks
_leaktracker61_fopen
_leaktracker61_fclose


你有什么理由拥有领先的下划线？我的意思是，如果

你只是省略它们，会发生什么？

在DEBUG模式下编译时，这些函数将在
全局命名空间，所以我试图限制名称冲突。

我想知道我是否可以将我的代码视为
实现的扩展，并且通过使用导致下划线避免名称
碰撞。

Section 17.4.3.1.2 states that each name that begins with an underscore
is reserved to the implementation for use as a name in the global
namespace.

Exactly what defines the implementation?
You''re the one who is reading the Standard. Doesn''t it define the
''implementation''?
Is it only narrowly defined by the compiler''s internal name handling?
Or does it also include the library that comes with the compiler?
What''s the title of Clause 17 (from which 17.4.3.1.2 comes)?
Does it include the OS library as part of the implementation?
Doesn''t it already say about that in the beginning of Clause 17?
I''m developing some portable leak tracking code, and for most functions
I can''t use namespaces in the header because the code has to be able to
compile to both C and C++ source files.

I''m trying to determine what would be the best naming convention to
use, and I''m considering something like the following:
_leaktracker61_free
_leaktracker61_realloc
_leaktracker61_DumpAllLeaks
_leaktracker61_fopen
_leaktracker61_fclose
What is the reason for you to have the leading underscores? I mean, if
you simply omit them, what''s going to happen?
When compiled in DEBUG mode, these functions are going to be in the
global namespace, so I''m trying to limit name collision.

I''m wondering if I can consider my code as an extension to the
implementation, and there by use the leading underscore to avoid name
collision.

它不是你为

编译器供应商工作的实现的扩展_unless_ 。是吗？


V

It is not an extension to the implementation _unless_ you work for the
compiler vendor. Do you?

V

Axter写道：

第17.4.3.1.2节声明每个以下划线开头的名称
都保留给实现，以用作全局
命名空间中的名称。


我的理解是领先的下划线是好的，只要它不是
后跟一个大写字母。引用您引用的部分：


"每个包含双下划线（_ _）的名称或以

开头的下划线后跟一个大写字母（2.11）保留给

实现任何用途。

我正在试图确定什么是最好的命名约定
使用，我正在考虑以下内容：
_leaktracker61_free
_leaktracker61_realloc
_leaktracker61_DumpAllLeaks
_leaktracker61_fopen
_leaktracker61_fclose

Section 17.4.3.1.2 states that each name that begins with an underscore
is reserved to the implementation for use as a name in the global
namespace.
My understanding is that a leading underscore is OK as long as it''s not
followed by an uppercase letter. To quote from the section you cited:

"Each name that contains a double underscore (_ _) or begins with
an underscore followed by an uppercase letter (2.11) is reserved to
the implementation for any use."
I''m trying to determine what would be the best naming convention to
use, and I''m considering something like the following:
_leaktracker61_free
_leaktracker61_realloc
_leaktracker61_DumpAllLeaks
_leaktracker61_fopen
_leaktracker61_fclose

这些应该没问题，不是因为你是一个实现。但

因为根据上述规则不保留名称。

These should be OK, not because you''re an "implementation" but
because the names are not reserved according to the above rules.

这篇关于领先的下划线的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！