blocks|key|1387571|text|通过函数指针调用函数比静态函数调用要慢一些，因为前者的调用包含一个额外的指针取消引用。但AFAIK在大多数现代机器上这种差异是可以忽略的(可能除了一些资源非常有限的特殊平台)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1387572|使用函数指针是因为它们可以使程序变得更简单、更整洁、更容易维护(当然，当使用得当时)。这足以弥补可能存在的非常微小的速度差异。|1387573|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|$]]

Calling a function via a function pointer is somewhat slower than a static function call, since the former call includes an extra pointer dereferencing. But AFAIK this difference is negligible on most modern machines (except maybe some special platforms with very limited resources).

Function pointers are used because they can make the program much simpler, cleaner and easier to maintain (when used properly, of course). This more than makes up for the possible very minor speed difference.

blocks|key|2795938|text|使用函数指针比只调用函数慢，因为它是另一个间接层。(需要解除对指针的引用才能获得函数的内存地址)。虽然它很慢，但与你的程序可能做的其他事情(读文件，写控制台)相比，它可以忽略不计。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2795939|如果你需要使用函数指针，那就使用函数指针，因为任何试图做同样事情但避免使用函数指针的事情都会比使用函数指针慢，而且更难维护。|2795940|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|$]]

Using a function pointer is slower that just calling a function as it is another layer of indirection. (The pointer needs to be dereferenced to get the memory address of the function). While it is slower, compared to everything else your program may do (Read a file, write to the console) it is negligible.

If you need to use function pointers, use them because anything that tries to do the same thing but avoids using them will be slower and less maintainable that using function pointers.

blocks|key|2795965|text|我认为当人们这样说的时候，他们指的是使用函数指针可能会阻止编译器优化(内联)和处理器优化(分支预测)。然而，如果函数指针是完成你想要做的事情的一种有效方法，那么任何其他的方法都有同样的缺点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2795966|除非您的函数指针在性能关键型应用程序或速度非常慢的嵌入式系统中的紧密循环中使用，否则差异可能是微不足道的。|2795967|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|$]]

I think when people say this they're referring to the fact that using function pointers may prevent compiler optimizations (inlining) and processor optimizations (branch prediction). However, if function pointers are an effective way to accomplish something that you're trying to do, chances are that any other method of doing it would have the same drawbacks.

And unless your function pointers are being used in tight loops in a performance critical application or on a very slow embedded system, chances are the difference is negligible anyway.

blocks|key|2796028|text|很多人已经提出了一些很好的答案，但我仍然认为有一点被遗漏了。函数指针确实增加了一个额外的解引用，这使得它们慢了几个周期，这个数字可以基于糟糕的分支预测而增加(顺便说一句，这几乎与函数指针本身无关)。此外，通过指针调用的函数不能内联。但人们忽略的是，大多数人使用函数指针作为优化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2796029|在c/c%2B%2B+API中，函数指针最常见的地方是作为回调函数。这么多API这样做的原因是，编写一个在事件发生时调用函数指针的系统比其他方法(如消息传递)效率高得多。就我个人而言，我还将函数指针用作更复杂的输入处理系统的一部分，其中键盘上的每个键都有一个通过跳转表映射到它的函数指针。这允许我从输入系统中删除任何分支或逻辑，只需处理进入的按键。|2796030|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|$]]

A lot of people have put in some good answers, but I still think there's a point being missed. Function pointers do add an extra dereference which makes them several cycles slower, that number can increase based on poor branch prediction (which incidentally has almost nothing to do with the function pointer itself). Additionally functions called via a pointer cannot be inlined. But what people are missing is that most people use function pointers as an optimization.

The most common place you will find function pointers in c/c++ APIs is as callback functions. The reason so many APIs do this is because writing a system that invokes a function pointer whenever events occur is much more efficient than other methods like message passing. Personally I've also used function pointers as part of a more-complex input processing system, where each key on the keyboard has a function pointer mapped to it via a jump table. This allowed me to remove any branching or logic from the input system and merely handle the key press coming in.

blocks|key|958372|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|958373|和每个人都说这会使我的程序运行缓慢。是真的吗？|blockquote|958374|958375|958376|这种说法很可能是错误的。例如，如果使用函数指针的替代方法类似于|958377|if+(condition1)+{
++++++++func1();
}+else+if+(condition2)
++++++++func2();
}+else+if+(condition3)
++++++++func3();
}+else+{
++++++++func4();
}|code-block|syntax|javascript|958378|这很可能比仅仅使用单个函数指针要慢得多。虽然通过指针调用函数确实有一些(通常可以忽略的)开销，但与比较相关的通常不是直接函数调用与通过指针调用的差异。|958379|其次，在没有任何测量的情况下，永远不要优化性能。要知道瓶颈在哪里是非常困难的(请参阅+it+)，有时这可能非常不直观(例如，linux内核开发人员已经开始从函数中删除inline关键字，因为它实际上会影响性能)。|offset|length|style|BOLD|CODE|958380|entityMap^0|0|0|0|0|0|0|0|16|4|2B|6|0^^$0|@$1|2|3|-4|4|5|6|X|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|Y|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|Z|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|10|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|11|7|@]|8|@]|9|$]]|$1|H|3|I|4|J|6|12|7|@]|8|@]|9|$K|L]]|$1|M|3|N|4|5|6|13|7|@]|8|@]|9|$]]|$1|O|3|P|4|5|6|14|7|@$Q|15|R|16|S|T]|$Q|17|R|18|S|U]]|8|@]|9|$]]|$1|V|3|-4|4|5|6|19|7|@]|8|@]|9|$]]]|W|$]]

<blockquote>
 And everyone said that will make my
 program run slow. Is it true?
</blockquote>

Most likely this claim is false. For one, if the alternative to using function pointers are something like

<pre><code>if (condition1) {
 func1();
} else if (condition2)
 func2();
} else if (condition3)
 func3();
} else {
 func4();
}
</code></pre>

this is most likely relatively much slower than just using a single function pointer. While calling a function through a pointer does have some (typically neglectable) overhead, it is normally not the direct-function-call versus through-pointer-call difference that is relevant to compare.

And secondly, never optimize for performance without any measurements. Knowing where the bottlenecks are is very difficult (read impossible) to know and sometimes this can be quite non-intuitively (for instance the linux kernel developers have started removing the <code>inline</code> keyword from functions because it actually hurt performance).

blocks|key|961486|text|您看，从性能的角度来看，在一些实际很重要的情况下，比如在一个周期中重复多次调用函数，性能可能根本不会有什么不同。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|961487|这对人们来说可能听起来很奇怪，他们习惯于将C代码看作是由抽象的C机器执行的东西，其“机器语言”紧密地反映了C语言本身。在这样的上下文中，“默认情况下”对函数的间接调用确实比直接调用慢，因为它正式地涉及到额外的内存访问，以便确定调用的目标。|961488|然而，在现实生活中，代码是由真实的机器执行的，并由优化编译器编译，该编译器对底层机器架构有很好的了解，这有助于它为特定机器生成最优的代码。在许多平台上，从循环执行函数调用的最有效方法实际上会导致直接调用和间接调用的代码相同，从而导致两者的性能相同。|961489|例如，考虑x86平台。如果我们“从字面上”将直接和间接调用转换成机器代码，我们可能会得到如下所示的结果|961490|//+Direct+call
do-it-many-times
++call+0x12345678

//+Indirect+call
do-it-many-times
++call+dword+ptr+[0x67890ABC]|code-block|syntax|javascript|961491|前者在机器指令中使用立即操作数，并且通常比后者更快，后者必须从一些独立的内存位置读取数据。|961492|在这一点上，让我们记住，x86架构实际上还有一种向call指令提供操作数的方法。它在寄存器中提供目标地址。关于这种格式的一个非常重要的事情是，它通常比上面两种格式都快。这对我们意味着什么？这意味着一个好的优化编译器必须并将利用这一事实。为了实现上述循环，编译器在这两种情况下都会尝试通过寄存器进行调用。如果成功，最终的代码可能如下所示|offset|length|style|CODE|961493|//+Direct+call

mov+eax,+0x12345678

do-it-many-times
++call+eax

//+Indirect+call

mov+eax,+dword+ptr+[0x67890ABC]

do-it-many-times
++call+eax|961494|请注意，现在重要的部分-循环体中的实际调用-在这两种情况下是完全相同的。不用说，性能几乎是一样的。|961495|有人甚至可能会说，无论听起来多么奇怪，在这个平台上，只要间接调用的操作数是在寄存器中提供的(而不是存储在内存中)，直接调用(带有call中的立即操作数的调用)就比间接调用慢。|961496|当然，在一般情况下，整个事情并不容易。编译器必须处理寄存器的有限可用性，别名问题等。但像你的例子(甚至在更复杂的情况下)这样的简单情况下，上述优化将由一个好的编译器执行，并将完全消除循环直接调用和循环间接调用之间的任何性能差异。当调用虚拟函数时，这种优化在C%2B%2B中工作得特别好，因为在典型的实现中，涉及的指针完全由编译器控制，使其完全了解别名图片和其他相关内容。|961497|当然，总是有一个问题是，你的编译器是否足够智能来优化这样的东西……|961498|entityMap^0|0|0|0|0|0|0|P|4|0|0|0|1S|4|0|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|18|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|19|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|1A|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|1B|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|1C|8|@$Q|1D|R|1E|S|T]]|9|@]|A|$]]|$1|U|3|V|5|J|7|1F|8|@]|9|@]|A|$K|L]]|$1|W|3|X|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1H|8|@$Q|1I|R|1J|S|T]]|9|@]|A|$]]|$1|10|3|11|5|6|7|1K|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|1L|8|@]|9|@]|A|$]]|$1|14|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|15|$]]

You see, in situations that actually matter from the performance point of view, like calling the function repeatedly many times in a cycle, the performance might not be different at all.

This might sound strange to people, who are used to thinking about C code as something executed by an abstract C machine whose "machine language" closely mirrors the C language itself. In such context, "by default" an indirect call to a function is indeed slower than a direct one, because it formally involves an extra memory access in order to determine the target of the call. 

However, in real life the code is executed by a real machine and compiled by an optimizing compiler that has a pretty good knowledge of the underlying machine architecture, which helps it to generate the most optimal code for that specific machine. And on many platforms it might turn out that the most efficient way to perform a function call from a cycle actually results in identical code for both direct and indirect call, leading to the identical performance of the two.

Consider, for example, the x86 platform. If we "literally" translate a direct and indirect call into machine code, we might end up with something like this

<pre><code>// Direct call
do-it-many-times
 call 0x12345678

// Indirect call
do-it-many-times
 call dword ptr [0x67890ABC]
</code></pre>

The former uses an immediate operand in the machine instruction and is indeed normally faster than the latter, which has to read the data from some independent memory location.

At this point let's remember that x86 architecture actually has one more way to supply an operand to the <code>call</code> instruction. It is supplying the target address in a register. And a very important thing about this format is that it is normally faster than both of the above. What does this mean for us? This means that a good optimizing compiler must and will take advantage of that fact. In order to implement the above cycle, the compiler will try to use a call through a register in both cases. If it succeeds, the final code might look as follows

<pre><code>// Direct call

mov eax, 0x12345678

do-it-many-times
 call eax

// Indirect call

mov eax, dword ptr [0x67890ABC]

do-it-many-times
 call eax
</code></pre>

Note, that now the part that matters - the actual call in the cycle body - is exactly and precisely the same in both cases. Needless to say, the performance is going to be virtually identical. 

One might even say, however strange it might sound, that on this platform a direct call (a call with an immediate operand in <code>call</code>) is slower than an indirect call as long as the operand of the indirect call is supplied in a register (as opposed to being stored in memory). 

Of course, the whole thing is not as easy in general case. The compiler has to deal with limited availability of registers, aliasing issues etc. But is such simplistic cases as the one in your example (and even in much more complicated ones) the above optimization will be carried out by a good compiler and will completely eliminate any difference in performance between a cyclic direct call and a cyclic indirect call. This optimization works especially well in C++, when calling a virtual function, since in a typical implementation the pointers involved are fully controlled by the compiler, giving it full knowledge of the aliasing picture and other relevant stuff.

Of course, there's always a question of whether your compiler is smart enough to optimize things like that...

blocks|key|212693|text|在之前的回复中有很多好的观点。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|212694|但是，看一看C的qsort比较函数。因为比较函数不能内联，并且需要遵循基于标准堆栈的调用约定，所以排序的总运行时间可以是整数键的数量级(更准确地说是3-10倍)，而不是使用直接的、可内联的调用的相同代码。|offset|length|style|BOLD|212695|典型的内联比较将是一系列简单的CMP和可能的CMOV/SET指令。函数调用还会产生调用、设置堆栈帧、执行比较、拆卸堆栈帧和返回结果的开销。请注意，由于CPU流水线长度和虚拟寄存器的原因，堆栈操作可能导致流水线停止。例如，如果在最后修改的eax完成执行的指令之前需要eax的值(在最新的处理器上通常需要大约12个时钟周期)。除非CPU可以无序地执行其他指令来等待，否则将发生流水线停顿。|212696|entityMap^0|0|1S|3|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

A lot of good points in earlier replies. 

However take a look at C qsort comparison function. Because the comparison function cannot be inlined and needs to follow standard stack based calling conventions, the total running time for the sort can be an order of magnitude (more exactly 3-10x) slower for integer keys, than otherwise same code with a direct, inlineable, call.

A typical inlined comparison would be a sequence of simple CMP and possibly CMOV/SET instruction. A function call also incurs the overhead of a CALL, setting up stack frame, doing the comparison, tearing down stack frame and returning the result. Note, that the stack operations can cause pipeline stalls due to CPU pipeline length and virtual registers. For example if value of say eax is needed before the instruction that last modified eax has finished executing (which typically takes about 12 clock cycles on the newest processors). Unless the CPU can execute other instructions out of order to wait for that, a pipeline stall will occur.

blocks|key|1387894|text|有可能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1387895|答案取决于函数指针的用途，以及替代方法是什么。如果函数指针被用来实现我们程序逻辑的一部分，并且不能简单地删除，那么将函数指针调用与直接函数调用进行比较是有误导性的。尽管如此，我还是会继续进行比较，然后再回到这个想法。|1387896|当函数指针调用禁止内联时，与直接函数调用相比，函数指针调用最有可能降低性能。因为内联是一种网关优化，所以我们可以在函数指针比等效的直接函数调用慢得多的情况下进行大量的病态操作：|1387897|void+foo(int*+x)+{
++++*x+=+0;
}

void+(*foo_ptr)(int*)+=+foo;

int+call_foo(int+*p,+int+size)+{
++++int+r+=+0;
++++for+(int+i+=+0;+i+!=+size;+%2B%2Bi)
++++++++r+%2B=+p[i];
++++foo(&r);
++++return+r;
}

int+call_foo_ptr(int+*p,+int+size)+{
++++int+r+=+0;
++++for+(int+i+=+0;+i+!=+size;+%2B%2Bi)
++++++++r+%2B=+p[i];
++++foo_ptr(&r);
++++return+r;
}|code-block|syntax|javascript|1387898|用于call_foo()的Code+generated|offset|length|style|CODE|1387899|call_foo(int*,+int):
++xor+eax,+eax
++ret|1387900|好的。foo()不仅被内联，而且允许编译器消除前面的整个循环！生成的代码只是通过XORing寄存器本身将返回寄存器置零，然后返回。另一方面，编译器将不得不在call_foo_ptr()中为循环生成代码(使用gcc+7.3的100%2B行)，并且大多数代码实际上什么也不做(只要foo_ptr仍然指向foo())。(在更典型的场景中，您可以预期将一个小函数内联到一个热内循环中可能会减少高达一个数量级的执行时间。)|1387901|因此，在最坏的情况下，函数指针调用比直接函数调用慢得多，但这是误导。事实证明，如果foo_ptr是const，那么call_foo()和call_foo_ptr()将生成相同的代码。然而，这将要求我们放弃foo_ptr提供的间接寻址的机会。让foo_ptr成为const是“公平的”吗？如果我们对foo_ptr提供的间接性感兴趣，那么不是，但如果是这样，那么直接函数调用也不是一个有效的选项。|1387902|如果函数指针被用来提供有用的间接性，那么我们可以移动间接性，或者在某些情况下将函数指针换成条件甚至宏，但我们不能简单地删除它。如果我们认为函数指针是一种很好的方法，但性能是一个问题，那么我们通常希望将间接调用堆栈向上拉起，这样我们就可以在外部循环中付出间接的代价。例如，在函数接受回调并在循环中调用它的常见情况下，我们可以尝试将最里面的循环移到回调中(并相应地更改每个回调调用的责任)。|1387903|entityMap|0|LINK|mutability|MUTABLE|url|https://godbolt.org/g/Tbwj9H^0|0|0|0|0|2|A|D|E|0|0|0|3|5|26|E|3S|7|43|5|0|15|7|1D|5|1L|A|1W|E|2U|7|3D|7|3M|5|44|7|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|18|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|19|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|1A|8|@$M|1B|N|1C|O|P]]|9|@$M|1D|N|1E|1|1F]]|A|$]]|$1|Q|3|R|5|H|7|1G|8|@]|9|@]|A|$I|J]]|$1|S|3|T|5|6|7|1H|8|@$M|1I|N|1J|O|P]|$M|1K|N|1L|O|P]|$M|1M|N|1N|O|P]|$M|1O|N|1P|O|P]]|9|@]|A|$]]|$1|U|3|V|5|6|7|1Q|8|@$M|1R|N|1S|O|P]|$M|1T|N|1U|O|P]|$M|1V|N|1W|O|P]|$M|1X|N|1Y|O|P]|$M|1Z|N|20|O|P]|$M|21|N|22|O|P]|$M|23|N|24|O|P]|$M|25|N|26|O|P]]|9|@]|A|$]]|$1|W|3|X|5|6|7|27|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|28|8|@]|9|@]|A|$]]]|Z|$10|$5|11|12|13|A|$14|15]]]]

Possibly.

The answer depends on what the function pointer is being used for and hence what the alternatives are. Comparing function pointer calls to direct function calls is misleading if a function pointer is being used to implement a choice that's part of our program logic and which can't simply be removed. I'll go ahead and nonetheless show that comparison and come back to this thought afterwards.

Function pointer calls have the most opportunity to degrade performance compared to direct function calls when they inhibit inlining. Because inlining is a gateway optimization, we can craft wildly pathological cases where function pointers are made arbitrarily slower than the equivalent direct function call:

<pre><code>void foo(int* x) {
 *x = 0;
}

void (*foo_ptr)(int*) = foo;

int call_foo(int *p, int size) {
 int r = 0;
 for (int i = 0; i != size; ++i)
 r += p[i];
 foo(&amp;r);
 return r;
}

int call_foo_ptr(int *p, int size) {
 int r = 0;
 for (int i = 0; i != size; ++i)
 r += p[i];
 foo_ptr(&amp;r);
 return r;
}
</code></pre>

<a href="https://godbolt.org/g/Tbwj9H" rel="nofollow noreferrer">Code generated</a> for <code>call_foo()</code>:

<pre><code>call_foo(int*, int):
 xor eax, eax
 ret
</code></pre>

Nice. <code>foo()</code> has not only been inlined, but doing so has allowed the compiler to eliminate the entire preceding loop! The generated code simply zeroes out the return register by XORing the register with itself and then returns. On the other hand, compilers will have to generate code for the loop in <code>call_foo_ptr()</code> (100+ lines with gcc 7.3) and most of that code effectively does nothing (so long as <code>foo_ptr</code> still points to <code>foo()</code>). (In more typical scenarios, you can expect that inlining a small function into a hot inner loop might reduce execution time by up to about an order of magnitude.)

So in a worst case scenario, a function pointer call is arbitrarily slower than a direct function call, but this is misleading. It turns out that if <code>foo_ptr</code> had been <code>const</code>, then <code>call_foo()</code> and <code>call_foo_ptr()</code> would have generated the same code. However, this would require us to give up the opportunity for indirection provided by <code>foo_ptr</code>. Is it "fair" for <code>foo_ptr</code> to be <code>const</code>? If we're interested in the indirection provided by <code>foo_ptr</code>, then no, but if that's the case, then a direct function call is not a valid option either.

If a function pointer is being used to provide useful indirection, then we can move the indirection around or in some cases swap out function pointers for conditionals or even macros, but we can't simply remove it. If we've decided that function pointers are a good approach but performance is a concern, then we typically want to pull indirection up the call stack so that we pay the cost of indirection in an outer loop. For example, in the common case where a function takes a callback and calls it in a loop, we might try moving the innermost loop into the callback (and changing the responsibility of each callback invocation accordingly).

I read about function pointers in C.
And everyone said that will make my program run slow.
Is it true?

I made a program to check it.
And I got the same results on both cases. (measure the time.)

So, is it bad to use function pointer?
Thanks in advance.

To response for some guys.
I said 'run slow' for the time that I have compared on a loop.
like this:

<pre><code>int end = 1000;
int i = 0;

while (i &lt; end) {
 fp = func;
 fp ();
}
</code></pre>

When you execute this, i got the same time if I execute this.

<pre><code>while (i &lt; end) {
 func ();
}
</code></pre>

So I think that function pointer have no difference of time
and it don't make a program run slow as many people said.

Does Function pointer make the program slow?

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

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

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

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

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

我在C语言中读到了函数指针，每个人都说这会使我的程序运行缓慢。是真的吗？我写了一个程序来检查它。我在两个案例中都得到了相同的结果。(测量时间。)那么，使用函数指针是不是很糟糕呢？提前谢谢。对一些人的回应。我说的是“慢跑”，因为我在循环中进行了比较。如下所示：int end = 1000;int i = 0;while ...

问函数指针是否会使程序变慢？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问函数指针是否会使程序变慢？EN