epoll_data_t问题(特别是关于C数据类型)

发布于 2024-08-16 20:37:53 字数 330 浏览 3 评论 0原文

联合 epoll_data_t 看起来像:

typedef union epoll_data {  
    void *ptr;  
    int fd;  
    __uint32_t u32;  
    __uint64_t u64;  
} epoll_data_t;

这更像是一个一般的 C 问题,但是为什么使用前导双下划线 __uint{32,64} 类型,而不是只使用不带下划线的 uint{32,64} 类型?我真的不明白为什么/何时使用下划线版本,但我认为不带下划线的 uint32 是在可向外界公开修改的联合中使用的正确选择。

The union epoll_data_t looks like:

typedef union epoll_data {  
    void *ptr;  
    int fd;  
    __uint32_t u32;  
    __uint64_t u64;  
} epoll_data_t;

This is more of a general C question, but why are the leading double underscores __uint{32,64} types used instead of just uint{32,64} without the underscores? I don't really understand why/when you would use the underscore version, but I thought that uint32 without underscores would be the proper thing to use in a union publicly modifiable to the outside world.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

蓝眸 2024-08-23 20:37:53

前导下划线保留给编译器/库供应商,以避免在全局命名空间中创建与客户创建的符号发生冲突的符号。不幸的是,客户也一直将其用于自己的“系统级”声明,第三方库供应商也是如此,迫使供应商开始使用两个下划线。带有 3 个下划线的符号已在野外被发现,但尚未广泛传播。

A leading underscore is reserved to the compiler/library vendor to avoid creating symbols in the global namespace that collide with symbols created by their customers. Unfortunately, customers have been using this too for their own "system level" declarations, as do 3rd party library vendors, forcing the vendors to start using two underscores. Symbols with 3 underscores have been found in the wild but are not yet wide-spread.

眉黛浅 2024-08-23 20:37:53

固定宽度整数类型已通过 C99 标准化。在此之前,编译器和库作者引入了他们自己的类型,这些可能是其中的残余;据我所知,MS 仍然没有随 Visul Studio 一起提供 stdint.h

Fixed-width integer types were standardized with C99. Before that, compiler and library authors introduced their own types, of which these might be a remnant; afaik MS still doesn't ship stdint.h with Visul Studio.

可是我不能没有你 2024-08-23 20:37:53

直接来自维基百科 [http://en.wikipedia.org/wiki/Underscore]

内部可能发生许多冲突
外部标识符链接空间
这可能会混合代码
由各种高层产生
需要编译器、运行时库
通过这些编译器中的每一个,编译器
生成的辅助函数,以及
程序启动代码,其中一些
分数不可避免地是由
系统汇编语言。在此范围内
冲突域下划线
性格很快就根深蒂固
主要机制为
区分外部链接
空间。这是 C 的常见做法
编译器在前面添加一个前导
对所有外部范围使用下划线
程序标识符以避免冲突
来自运行时的贡献
语言支持。此外,当
需要引入C/C++编译器
名称作为外部链接的一部分
翻译过程,这些名字
经常与某些人区分开来
多个前导或的组合
尾随下划线。

Directly from wikipedia [http://en.wikipedia.org/wiki/Underscore]

Many clashes were possible within the
external identifier linkage space
which potentially mingles code
generated by various high level
compilers, runtime libraries required
by each of these compilers, compiler
generated helper functions, and
program startup code, of which some
fraction was inevitably compiled from
system assembly language. Within this
collision domain the underscore
character quickly became entrenched as
the primary mechanism for
differentiating the external linkage
space. It was common practice for C
compilers to prepend a leading
underscore to all external scope
program identifiers to avert clashes
with contributions from runtime
language support. Furthermore, when
the C/C++ compiler needed to introduce
names into external linkage as part of
the translation process, these names
were often distinguished with some
combination of multiple leading or
trailing underscores.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文