C++内存对齐问题
一行代码胜过一千个字:) 这是我的问题:
/* Platform specific 16-byte alignment macro switch.
On Visual C++ it would substitute __declspec(align(16)).
On GCC it substitutes __attribute__((aligned (16))).
*/
#define ALIGN_16 ...
struct ALIGN_16 A {...};
A* ptr = new A;
A* ptr2 = new A[20];
assert(size_t(ptr) % 16 == 0);
for (int i=0; i<20; ++i)
assert(size_t(ptr2+i) % 16 == 0);
assert(sizeof(A) % 16 == 0);
我可以期望所有断言都在支持 SSE 的平台上传递吗?谢谢。
编辑。部分答案。我用VS2008、GCC和ICC做了一些测试。 MS编译器确实对齐了ptr和ptr2,但GCC和ICC未能对齐ptr2。
A line of code is worth a thousand words :) Here is my problem:
/* Platform specific 16-byte alignment macro switch.
On Visual C++ it would substitute __declspec(align(16)).
On GCC it substitutes __attribute__((aligned (16))).
*/
#define ALIGN_16 ...
struct ALIGN_16 A {...};
A* ptr = new A;
A* ptr2 = new A[20];
assert(size_t(ptr) % 16 == 0);
for (int i=0; i<20; ++i)
assert(size_t(ptr2+i) % 16 == 0);
assert(sizeof(A) % 16 == 0);
Can I expect that all assertions pass on platforms with SSE support? Thank you.
EDIT. Partial answer. I did some test with VS2008, GCC and ICC. MS compiler did align both ptr and ptr2, but GCC and ICC failed to align ptr2.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
有吗C++ 的新操作是否能保证地址返回的对齐?
换句话说,您可以使用该标准来证明您的假设是正确的,即它应该有效,但实际上,它可能会在您面前爆炸。
Visual C++ 6 没有正确对齐通过
new
分配的double
,所以就这样了。Is there any guarantee of alignment of address return by C++'s new operation?
In other words, you can use the standard to justify your assumption that it should work, but in practice, it may blow up in your face.
Visual C++ 6 did not align
doubles
allocated vianew
properly, so there you go.C++0x 提供了一个新的构造(在 [meta.type.synop] 20.7.6.6 其他转换中):
据我所知,它保证始终正确对齐记起。
第二个参数是可选的,默认为最严格的要求(因此不精确它总是安全的,但如果您愿意尝试,您可以更紧凑地打包您的类型)。
除了错误之外,编译器必然会满足该要求。如果您没有 C++0x,则可以在
tr1
命名空间或Boost
上找到它。您是唯一可以测试您的特定编译器是否满足此请求的人:)
注意:在
gcc-4.3.2
上,它的实现如下:C++0x provides a new construct (in [meta.type.synop] 20.7.6.6 other transformations):
which is guaranteed to be always correctly aligned as far as I recall.
The second parameter is optional, and defaults to the most stringent requirement possible (so that it's always safe not to precise it, but that you may pack your types more compactly if you are willing to try).
Apart from bugs, the compiler is bound to honor the requirement. If you do not have C++0x, this may be found in the
tr1
namespace or onBoost
.You're the only one who can test that your particular compiler does honor this request :)
Note: on
gcc-4.3.2
, it is implemented as: