是不是有时间有标准的对齐声明？ [英] Isn't it time there was a standard align statement?
问题描述
如果下一个版本的
C语言实际上允许对数据进行一些便携式控制，那将是非常愉快的（在我看来）
alignment。 />
这些东西的编译器特定机制是如此多样化，以至于甚至无法将详细信息抽象为
预处理器宏。
我想看到的：
/ *每个结构对齐* /
align（ 16）struct xyz {
char x;
char y;
int z;
};
/ *每个成员对齐（显然在第一个
成员之前填充是非法的，所以整个结构将会对齐
case * /
align（16）struct xyz {
align（16）char x;
char y;
int z;
};
/ *每个变量对齐* /
align（16）unsigned int x;
我不在乎语法。
现在，显然，C意味着可以实现从
自我感知的天气控制大型机到机动式领带架，
所以在这种情况下主机实现不支持指定的
对齐，应该发出警告，并且应该给出最接近或
自然对齐。显然可以通过编译器特定的开关发出警告
致命 - 这与
语言无关。
它似乎真的应该标准化，因为它显然
对于需要接近
硬件但不想要的大量程序员很有用迷失汇编代码（想想Altivec，
SSE）。
听起来像是C语言的重点，不是吗？
如果编译器实现者想出了一个模糊可移植的方法，我不会介意这么多，但他们甚至都没有接近。
GCC和英特尔赢得了''最愉快的
实施'的联合一等奖''
虽然（__attribute__或_declspec（））。
欢呼，
MC
It''d be really pleasant (in my opinion) if the next revision of the
C language actually allowed some portable control over data
alignment.
Compiler-specific mechanisms for this stuff are so varied that
it becomes impossible to even abstract the details away behind
preprocessor macros.
What I''d like to see:
/* per structure alignment */
align(16) struct xyz {
char x;
char y;
int z;
};
/* per member alignment (obviously padding before the first
member is illegal, so the entire structure would become aligned
in this case */
align(16) struct xyz {
align(16) char x;
char y;
int z;
};
/* per variable alignment */
align(16) unsigned int x;
I don''t care about the syntax.
Now, obviously, C is meant to be implemented on everything from
self-aware weather-control mainframes, to motorized tie racks,
so in the case of the host implementation not supporting the specified
alignment, a warning should be emitted and either the closest or
natural alignment should be given. Warnings can obviously be made
fatal with compiler specific switches - and that''s no business of the
language.
It just seems that this really should be standardized as it clearly
is useful for a vast number of programmers who need to get close to the
hardware but don''t want to stray into assembly code (think Altivec,
SSE).
Sounds like EXACTLY the point of the C language, doesn''t it?
I wouldn''t mind so much if compiler implementors had come up with a
vaguely portable way of doing this, but they haven''t even come close.
GCC and Intel have won joint first prize for ''most pleasant
implementation''
though (__attribute__ or _declspec()).
cheers,
MC
推荐答案
< ar *** *******@googlemail.com写信息
新闻：11 ********** ************@s34g2000cwa.googlegr oups.com ...
<ar**********@googlemail.comwrote in message
news:11**********************@s34g2000cwa.googlegr oups.com...
这真的很愉快（在我看来）如果下一个版本的
C语言实际上允许对数据进行一些便携式控制
对齐。
这似乎就是这个真的应该标准化，因为它显然
对于大量需要接近
硬件但不想误入汇编代码的程序员很有用（想想Altivec，
SSE）。
听起来像是C语言的重点，不是吗？
It''d be really pleasant (in my opinion) if the next revision of the
C language actually allowed some portable control over data
alignment.
It just seems that this really should be standardized as it clearly
is useful for a vast number of programmers who need to get close to the
hardware but don''t want to stray into assembly code (think Altivec,
SSE).
Sounds like EXACTLY the point of the C language, doesn''t it?
您的帖子相当一般，并没有给出当前C机制不足的
场景的具体示例。
请不要对该语言进行一般性批评。相反，发布一个
特定的一些效果或最终结果的例子，你试图实现和
为什么你认为你不能用当前的机制做到这一点。
我总能找到适当的机制。如果对齐是
未知或者您需要使用指针执行双重任务，只需定义一个变量
记录并让编译器弄清楚...
Your post is rather general and doesn''t give a specific example of a
scenario where the current C mechanisms are inadequate.
Please don''t make general criticisms of the language. Instead, post a
specific example of some effect or end-result you are trying to achieve and
why you believe you can''t do it with the current mechanisms.
I''ve always found the current mechanisms to be adequate. Where alignment is
unknown or you need to do double-duty with a pointer, just define a variant
record and let the compiler figure it out ...
ar ********** @ googlemail。 com 写道：
如果下一次修订
C，那将是非常愉快的（在我看来）语言实际上允许对数据进行一些便携式控制
对齐。
编译器特定的机制对于这些东西是多种多样的
it甚至不可能将细节抽象出来。
预处理器宏。
我想看到的：
/ *每个结构对齐* /
align（16）struct xyz {
char x;
char y;
int z;
};
It''d be really pleasant (in my opinion) if the next revision of the
C language actually allowed some portable control over data
alignment.
Compiler-specific mechanisms for this stuff are so varied that
it becomes impossible to even abstract the details away behind
preprocessor macros.
What I''d like to see:
/* per structure alignment */
align(16) struct xyz {
char x;
char y;
int z;
};
为什么你会喜欢看这个？如果你正在处理某个特定硬件的特定编译器，你可以使用任何特定于编译器的机制。
但如果你正在寻求便携式控制，如何便携是
幻数16？
Why would you "like to see" this? If you''re dealing with
a particular compiler for a particular piece of hardware, you
can use whatever compiler-specific mechanisms are provided.
But if you''re seeking "portable control," how portable is the
magic number 16?
[...]
所以在这种情况下如果主机实现不支持指定的
对齐，则应发出警告，并且应给出最接近或
自然对齐。显然可以使用编译器特定的开关警告
致命 - 而且这不是
语言的业务。
[...]
so in the case of the host implementation not supporting the specified
alignment, a warning should be emitted and either the closest or
natural alignment should be given. Warnings can obviously be made
fatal with compiler specific switches - and that''s no business of the
language.
如果不同的实现可以随意使用
指令，那么便携式是什么？是吗？和寄存器一样，你可以写b / b，并确保所有编译器都接受它，但是和
注册一样，你真的不知道它对它有什么影响。代码。
If different implementations can do whatever they please with
the directive, how "portable" is it? As with register you can
write it and be assured all compilers will accept it, but as with
register you don''t really know what effect it will have on the code.
看起来这真的应该标准化，因为它很明显
对于需要获得的大量程序员来说很有用接近
硬件，但不想误入汇编代码（想想Altivec，
SSE）。
It just seems that this really should be standardized as it clearly
is useful for a vast number of programmers who need to get close to the
hardware but don''t want to stray into assembly code (think Altivec,
SSE).
我不熟悉它们，但我认为它们是机器
具有不寻常和挑剔的对齐限制。很好，然后：
你可以在align（N）指令中放置什么* one *值，这样
数据将根据需要在这两台机器上对齐还有其他所有人的
？换句话说，如果你担心这些细节似乎是便携性的话。已经不再是一个问题了。
I''m not familiar with them, but I''ll suppose they''re machines
with unusual and finicky alignment constraints. Very well, then:
What *one* value can you put inside an align(N) directive such that
the data will be aligned as desired on both of these machines and
on all others, too? To put it another way, if you are concerned
about such details it seems "portability" has already ceased to be
a concern.
听起来像C语言的确切点，不是吗？
Sounds like EXACTLY the point of the C language, doesn''t it?
你需要问dmr，但我不这么认为。
You''ll need to ask dmr, but I don''t think so.
如果编译器实现者想出了一个模糊的便携式方法，我就不会这么想了，但是他们甚至都没有接近。
GCC英特尔赢得了最令人愉快的实施的联合一等奖'
虽然（__attribute__或_declspec（））。
I wouldn''t mind so much if compiler implementors had come up with a
vaguely portable way of doing this, but they haven''t even come close.
GCC and Intel have won joint first prize for ''most pleasant
implementation''
though (__attribute__ or _declspec()).
数据对齐的细节本身是不可移植的，所以
开发便携式控制它们的动机似乎
小。每当你判断出这样和那样的对齐时，你就会立即限制代码的可移植性
。我只能看到你提出一种便携式的方式来宣称一段代码是不便携的。
-
Eric Sosman
es ***** @ acm-dot-org.inva 盖
ar ****** **** @ googlemail.com 写道：
>
这将是非常愉快的（在我的意见）如果下一次修改
C语言实际上允许对数据进行一些便携式控制
对齐。
>
It''d be really pleasant (in my opinion) if the next revision of
the C language actually allowed some portable control over data
alignment.
对齐不是为了编译器的好处，而是为了允许
编译器使用目标机器。
< br $> b $ b -
计算机软件行业最惊人的成就
是它继续取消稳定而惊人的
计算机硬件行业的收益...... - Petroski
Alignment is not for the benefit of the compiler, but to allow the
compiler to use the destination machine.
--
"The most amazing achievement of the computer software industry
is its continuing cancellation of the steady and staggering
gains made by the computer hardware industry..." - Petroski
这篇关于是不是有时间有标准的对齐声明？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
