且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

转换一个字节数组以允许赋值

更新时间:2023-11-15 18:24:22

quantumred写道:
quantumred wrote:

>

我发现下面的代码漂浮在某个地方我想要

得到一些评论。


unsigned char a1 [4] = {5,10,15,20};

unsigned char a2 [4] = {25 ,30,35,40};


*(unsigned int *)a1 = *(unsigned int *)a2;


//现在a1 [0] = a2 [0],a1 [1] = a2 [1]等等。


这是一个字节数组,将其转换为4字节整数指针,

然后取消引用它,然后分配它。这导致数组a1的内容复制到数组a2。 (更正我的解释

欢迎)


我不知道为什么这样做。我的第一直觉是使用memcpy

。这比memcpy快吗?是否有任何危险

除了潜在的int不是4字节?
>
I found the following code floating around somewhere and I''d like to
get some comments.

unsigned char a1[4]= { 5,10,15,20};
unsigned char a2[4]= { 25,30,35,40};

*(unsigned int *)a1=*(unsigned int *)a2;

// now a1[0]=a2[0], a1[1]=a2[1], etc.

This is taking a byte array, casting it to a 4 byte integer pointer,
then dereferencing it, then assigning it. This results in the contents
of array a1 copied to array a2. (corrections to my interpretation
welcome)

I don''t know why this was done this way. My first instinct would have
been to use memcpy. Is this faster than memcpy? Are there any dangers
other than the potential for int not being 4 bytes?



有可能a1和a2没有

对于unsigned类型有正确的对齐方式。


-

pete

There''s the possibility that a1 and a2 don''t
have the proper alignment for type unsigned.

--
pete




可能比memcpy快一点,没有函数调用开销。


prob。如果你知道你的编译器如何处理这些类型,你可以安全地使用

为你的编译器设置合适的命令行参数(或使用一些

pragma)

强制对齐等等。


不值得我怀疑的麻烦:完全不清楚什么是

正在发生,并且

你会节省多少?关于P4 / Athlon /等的一些说明是没有的!


probably a little quicker then memcpy, no function call overhead.

prob. safe if you know how your compiler treats these types, or you can
set appropriate command line params to your compiler (or use some
pragmas)
to force alignment and so on.

Not really worth the trouble i suspect though: not at all clear what is
happening, and
what you gonna save? a few instructions on a P4/Athlon/etc is nothin!


Aaron Gage写道:


请引用你回答的是,谷歌现在让这很容易。请参阅

我的信号中的最后一个链接获取更多信息。


有问题的代码是:
Aaron Gage wrote:

Please quote what you are replying to, Google now makes this easy. See
the last link in my sig for more information.

The code in question was:

quantumred写道:
quantumred wrote:


我发现下面的代码漂浮在某个地方我想要

得到一些评论。


unsigned char a1 [4] = {5,10,15,20};

unsigned char a2 [4] = {25, 30,35,40};


*(unsigned int *)a1 = *(unsigned int *)a2;


//现在a1 [0] = a2 [0],a1 [1] = a2 [1]等。


这是一个字节数组,将其转换为4字节整数指针,

然后取消引用它,然后分配它。这导致数组a1的内容复制到数组a2。 (更正我的解释

欢迎)


我不知道为什么这样做。我的第一直觉是使用memcpy

。这比memcpy快吗?是否有任何危险

除了潜在的int不是4字节?

I found the following code floating around somewhere and I''d like to
get some comments.

unsigned char a1[4]= { 5,10,15,20};
unsigned char a2[4]= { 25,30,35,40};

*(unsigned int *)a1=*(unsigned int *)a2;

// now a1[0]=a2[0], a1[1]=a2[1], etc.

This is taking a byte array, casting it to a 4 byte integer pointer,
then dereferencing it, then assigning it. This results in the contents
of array a1 copied to array a2. (corrections to my interpretation
welcome)

I don''t know why this was done this way. My first instinct would have
been to use memcpy. Is this faster than memcpy? Are there any dangers
other than the potential for int not being 4 bytes?


可能比memcpy快一点,没有函数调用开销。
probably a little quicker then memcpy, no function call overhead.



在大多数现代编译器中,速度可能没有差别。

On most modern compiler there is probably no difference in speed.


prob。如果你知道你的编译器如何处理这些类型,你可以安全地使用

为你的编译器设置合适的命令行参数(或使用一些

pragma)

强制对齐等等。
prob. safe if you know how your compiler treats these types, or you can
set appropriate command line params to your compiler (or use some
pragmas)
to force alignment and so on.



绝对*不*安全。它可能适用于OPs特定的平台,但

它是不安全的,因为代码可能会在一个系统上重复使用,而这个系统没有工作。

它不起作用。

Definitely *not* safe. It might work on the OPs specific platform, but
it is not safe because the code might then get reused on a system where
it does not work.


不值得我怀疑的麻烦:一点也不清楚

发生了什么,以及

你要节省的?关于P4 / Athlon /等的一些说明是没有的!
Not really worth the trouble i suspect though: not at all clear what is
happening, and
what you gonna save? a few instructions on a P4/Athlon/etc is nothin!



绝对不值得这么麻烦。

-

Flash Gordon,生活在有趣的时代。

网站 - http://home.flash-gordon。 me.uk/

comp.lang.c发布指南和介绍:
http://clc-wiki.net/wiki/Intro_to_clc