blocks|key|2076476|text|它们应该是相同的。但是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2076477|for(+i+=+0;+i+<+...;+%2B%2B+i+)+...+array[i]+...|code-block|syntax|javascript|2076478|可能比以下内容更慢：|2076479|for(+p+=+array;+*p;+%2B%2B+p+)+...+*p+...|2076480|因为在前一种情况下，编译器可能需要执行*(array%2Bi)，而在后一种情况下，您只需要执行(*p)。|offset|length|style|CODE|2076481|然而，在微不足道的情况下，编译器应该能够优化并生成相同的机器代码。|2076482|entityMap^0|0|0|0|0|J|A|19|4|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|W|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|Y|8|@$M|Z|N|10|O|P]|$M|11|N|12|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|13|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|T|$]]

They should be the same. But:

<pre><code>for( i = 0; i &lt; ...; ++ i ) ... array[i] ...
</code></pre>

could be slower than:

<pre><code>for( p = array; *p; ++ p ) ... *p ...
</code></pre>

because in the former case compiler could need to do <code>*(array+i)</code>, while in the second you just do <code>(*p)</code>.

In trivial cases, however, compiler should be able to optimize and generate the same machine code.

blocks|key|1332177|text|它们是完全等价的。数组访问是指针数学的语法糖。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1332178|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

They are exactly equivalent. Array access is syntactic sugar for pointer math.

blocks|key|1332187|text|不，根据C和C%2B%2B标准，a[i]在定义上等同于*(a%2Bi)。这也意味着a[1]等同于1[a]。尝试一下:)|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1332188|entityMap^0|C|4|N|6|Z|4|16|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|G|$]]

No, according to the C and C++ standards <code>a[i]</code> is by definition equivalent to <code>*(a+i)</code>. this also implies that <code>a[1]</code> is equivalent to <code>1[a]</code>. Try it :)

blocks|key|5040579|text|见鬼，不！a[i]总是等同于*(a%2Bi)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|5040580|a[i]+=+*(a+%2B+i)+=+*(i+%2B+a)+=i[a];|5040581|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/381542/in-c-arrays-why-is-this-true-a5-5a/381549#381549^0|5|4|E|6|0|0|X|0|X|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@$9|X|A|Y|1|Z]]|E|$]]|$1|H|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

Hell No! <code>a[i]</code> is always equivalent to <code>*(a+i)</code>. 

<a href="https://stackoverflow.com/questions/381542/in-c-arrays-why-is-this-true-a5-5a/381549#381549"><code>a[i] = *(a + i) = *(i + a) =i[a];</code></a>

blocks|key|5040760|text|在x86或x86_64上，使用p[i]或*(p%2Bi)+(注意:这两种形式在C语言中是相同的)可能比在循环的每个步骤中递增p更快，假设您已经需要将i用于其他目的。x86架构对基址/偏移量的使用具有高效的寻址，包括将偏移量按2的小幂进行缩放。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|5040761|另一方面，如果您可以通过递增p来消除i，则可以减少循环中所需的寄存器数量，从而实现进一步的优化。以下是关于x86各种情况下的相对成本的一些快速想法：|5040762|5040763|如果数组a在非PIC编译的代码中具有静态存储持续时间(static或extern全局)，则a[i]和*p+(不带i)方法使用相同数量的寄存器(例如，D18和0xdeadbeef(,%25ecx,4)是自动的(局部堆栈变量)，而不是可变长度数组，D19和D20方法使用相同数量的寄存器(例如，D21和D22，其中D23、堆栈指针、|unordered-list-item|5040764|如果您的数组a具有静态存储持续时间，并且您的代码被编译为PIC，则a[i]可能比*p方法的开销要高得多，即使您无论如何都必须将i保留在其他目的。|5040765|如果您的数组代码不是当前作用域中的数组变量，而是指向从其他地方传递到函数的数组的指针，则<+a+>d33比*p多占用一个寄存器(例如，d35+vs|5040766|5040767|entityMap^0|F|4|K|6|1O|1|20|1|0|E|1|I|1|0|0|4|1|R|6|Y|6|19|4|1E|2|1K|1|26|J|0|6|1|X|4|14|2|1R|1|0|1A|1|1H|2|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]|$9|V|A|W|B|C]|$9|X|A|Y|B|C]|$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|11|8|@$9|12|A|13|B|C]|$9|14|A|15|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|16|8|@]|D|@]|E|$]]|$1|I|3|J|5|K|7|17|8|@$9|18|A|19|B|C]|$9|1A|A|1B|B|C]|$9|1C|A|1D|B|C]|$9|1E|A|1F|B|C]|$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]|$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|L|3|M|5|K|7|1M|8|@$9|1N|A|1O|B|C]|$9|1P|A|1Q|B|C]|$9|1R|A|1S|B|C]|$9|1T|A|1U|B|C]]|D|@]|E|$]]|$1|N|3|O|5|K|7|1V|8|@$9|1W|A|1X|B|C]|$9|1Y|A|1Z|B|C]]|D|@]|E|$]]|$1|P|3|-4|5|6|7|20|8|@]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|21|8|@]|D|@]|E|$]]]|R|$]]

On x86 or x86_64, using <code>p[i]</code> or <code>*(p+i)</code> (note: these two forms are identical in the C language) may be faster than incrementing <code>p</code> at each step of the loop, assuming you need to keep <code>i</code> around for some other purpose already. The x86 architecture has efficient addressing for base/offset usage like this, including scaling the offset by small powers of 2.

On the other hand, if you can eliminate <code>i</code> by incrementing <code>p</code>, you may reduce the number of registers needed in you loop, which could allow further optimization. Here are some quick thoughts on the relative cost in various cases on x86:

<ul>
<li>If you array <code>a</code> has static storage duration (<code>static</code> or <code>extern</code> global) in non-PIC-compiled code, the <code>a[i]</code> and <code>*p</code> (with no <code>i</code>) methods use the same number of registers (e.g. <code>0xdeadbeef(,%ecx,4)</code> vs <code>(%esi)</code>).</li>
<li>If Your array <code>a</code> is automatic (local stack variable) and not a variable-length array, the <code>a[i]</code> and <code>*p</code> methods use the same number of registers (e.g. <code>12(%esp,%ecx,4)</code> vs <code>(%esi)</code> where <code>%esp</code>, the stack pointer, is already reserved anyway).</li>
<li>If your array <code>a</code> has static storage duration and your code is compiled as PIC, <code>a[i]</code> is probably significantly more expensive than the <code>*p</code> method, even if you have to keep <code>i</code> around for another purpose anyway.</li>
<li>If your array <code>a</code> is not an array variable in the current scope, but a pointer to an array passed to your function from somewhere else, then <code>a[i]</code> takes one more register than <code>*p</code> (e.g. <code>(%eax,%ecx,4)</code> vs <code>(%esi)</code>).</li>
</ul>

blocks|key|1332231|text|在某些情况下，可能会出现如下情况|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1332232|while+(*s%2B%2B+=+*d%2B%2B)
+++;|code-block|syntax|javascript|1332233|可能会比|1332234|while+(s[i]+=+d[i])
+++i%2B%2B;|1332235|但即使是这样，也可能会被优秀的编译器优化掉。|1332236|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

There may be some circumstances where something like

<pre><code>while (*s++ = *d++)
 ;
</code></pre>

might be faster than

<pre><code>while (s[i] = d[i])
 i++;
</code></pre>

but even that will probably be optimized away by good compilers.

blocks|key|5040598|text|编译器会将它们转换成指针代码，这只会让它们更容易使用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5040599|将数组运算符视为指针等效项的内联函数。|5040600|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The compiler will translate them to pointer code anyway, it just makes it easier to use them.

Think of array operator as an inline function for the pointer equivalent.

blocks|key|5040694|text|它们是等效的。但是使用数组语法的算法通常是这样写的|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5040695|int+a[];
for+(int+n+=+0;+n+<+size;+n%2B%2B)+{+...+Do+stuff+with+a[n];+}|code-block|syntax|javascript|5040696|每访问一次a元素需要多加一次|offset|length|style|CODE|5040697|int+a[size];
int+*end+=+a+%2B+size;
for+(int+*i+=+a;+i+!=+end;+%2B%2Bi)+{+...+Do+the+same+stuff+with+*i+;+}|5040698|有些编译器可能会将第一个版本优化为第二个版本。|5040699|entityMap^0|0|0|5|1|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@$I|V|J|W|K|L]]|9|@]|A|$]]|$1|M|3|N|5|D|7|X|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

They are equivalent. But algorithms that use the array syntax are typically written

<pre><code>int a[];
for (int n = 0; n &lt; size; n++) { ... Do stuff with a[n]; }
</code></pre>

which needs one more addition for each access to an element of <code>a</code> than

<pre><code>int a[size];
int *end = a + size;
for (int *i = a; i != end; ++i) { ... Do the same stuff with *i ; }
</code></pre>

Some compilers might optimize the first version into the second though.

blocks|key|3629659|text|很明显，这不是他的意思，这应该会有帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3629660|//+which+is+faster?+*t+or+t[i]?
process_some_array(T+*t,+size_t+n)
{
++++T+*end+=+&t[n];
++++for+(T+*t+=+t;+t+<+end;+%2B%2Bt)
++++++++//+do+stuff+with+*t
++++for+(size_t+i+=+0;+i+<+n;+%2B%2Bi)
++++++++//+do+stuff+with+t[i]
}|code-block|syntax|javascript|3629661|答案不是只要你的编译器没有任何优化。对于一般情况，您不应该担心差异，因为如果存在的话，它是微不足道的。此外，对于您自己和您的同事来说，解析和调试通常更容易。|3629662|如果这不是你的意思，恐怕这是一个愚蠢的问题，请看另一个答案。|3629663|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

It's obvious that's not what he means, this should help.

<pre><code>// which is faster? *t or t[i]?
process_some_array(T *t, size_t n)
{
 T *end = &amp;t[n];
 for (T *t = t; t &lt; end; ++t)
 // do stuff with *t
 for (size_t i = 0; i &lt; n; ++i)
 // do stuff with t[i]
}
</code></pre>

The answer is not as long as your compiler has no optimization whatsoever. For the general case you should not worry about the difference, as it is miniscule if present at all. Furthermore it's generally easier for yourself, and your fellows to parse and debug.

If this is not what you meant, I'm afraid it's a stupid question, see one of the other answers.

blocks|key|3629744|text|指针和数组都是通过address.Array访问的，它们的行为就像一个常量指针，指针用来保存任何value.So的地址，相同的事情是都通过地址访问值。正因为如此，两者是完全等价的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3629745|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Pointer and Array both are accessing through address.Array is behave like a constant pointer and pointer used to hold the address of any value.So same thing is both access the value through address. On account of that both are exactly equivalent.

With current C compilers, is it still true that using the array syntax (a[i]) is slower than using pointers (*(p+i))?

Is it still true that using pointers is significantly faster than using the array syntax in C?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

在当前的C编译器中，使用数组语法(ai)比使用指针(*(p+i))慢是真的吗？

问在C中使用指针比使用数组语法要快得多，这是真的吗？
EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在C中使用指针比使用数组语法要快得多，这是真的吗？EN

回答 10

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在C中使用指针比使用数组语法要快得多，这是真的吗？
EN