什么事情(或在什么情况下)可以使C ++比C慢?

这是一个面试问题,面试已经完成。

什么东西可以使C ++比C慢?

面试官问得很深,每当我说些什么时总是问“别的什么?”。

我的想法:

C中没有的C ++function可能会有一些成本。

例如,如果我们使用赋值来在构造函数内初始化类的成员而不是初始化列表,则可以在构造函数的主体之前调用成员的默认构造函数,然后通过赋值消除该值。

需要通过搜索虚函数指针来调用虚函数。 这是一个开销。

还有更好的想法?

任何帮助将不胜感激。

谢谢 !!!

没有。 事实上,C ++比C更快。曾经将std::sortqsort

人们说虚拟function需要花费时间来打电话。 他们是这样。 但是相当于在vtable中查找的C也是如此。 如果您在两种语言中编写等效逻辑,则C ++版本将更易于维护,更清晰,更快速。

编辑:哦,是的,你可以根据需要从C ++调用printf ,或者如果你愿意,可以完全重新执行流实现。

我是否提到由于错误的NULL终止符导致崩溃的程序的性能相当不重要?

宏和内联函数将像C ++中的模板一样“膨胀”C可执行文件。

C ++与C相比没有什么本质上更慢的速度,但是惯用的C ++代码往往比执行相同任务的惯用C代码慢得多,也更重。 惯用这个词在这里是关键; 如果您编写C代码来执行任务的方式与在C ++中执行该任务的方式完全相同,那么它的速度也会一样慢。 另一方面,如果您知道隐藏成本通常会在C ++中出现的地方,那么您可以努力将它们保持在最低限度,并在没有多少成本的情况下获得C ++的好处。

首先是动态内存分配。 在C中,您可以看到您所做的每一点动态内存分配,因为它都是显式的(以对malloc的调用或对返回已分配对象的第三方库函数的调用的forms)。 在C ++中,对象的存储持续时间是自动的许多类对象仍将导致动态内存分配,因为它们的构造函数中发生了隐藏的分配。 一个好的C ++ STL(或第三方库)实现可以通过在对象本身中包含小缓冲区来避免大量的这种成本,并且仅在需要大缓冲区时执行动态分配,但实际上很少这样做。 (如果我没弄错的话,llvm的libc ++会这样做,但是GCC的libstdc ++没有。)因为这是一个通常不受你自己的代码控制的实现质量问题,你可以做的最大限度地减少影响的是意识到自动对象分配动态内存的可能性,并避免创建超出您需要的内容(例如,尽可能使用指针或引用)。 这对您的代码也有其他好处。

另一个重要领域是字符串处理。 在惯用语C中,字符串是用snprintf或类似方法一次构造的。 在C ++和许多其他具有更强大的字符串类/类型的语言中,字符串的连接(逐个构造)是惯用的。 这是非常低效的,导致多个分配/解除分配步骤,副本等,更不用说产生的内存碎片。 我不确定C ++的最佳实践是什么(我不精通C ++),但应该有办法减少这种影响。

当然,最常见的是隐藏代码。 这是一种全能的方式。 在C ++中编写代码非常容易,因此很多额外的代码都会被执行。 构造函数/析构函数,重载运算符和模板是最明显的原因。 同样,如果你想在C中以相同的方式做事,成本将是相同的,但不同的是,在C中,你会立即看到成本,因为你必须自己编写。

哇…在答案中对C ++有很多的爱,所以我会像Devil的倡导者那样咆哮。

在primefaces语言规模上,我同意在C ++中很少或根本没有显着“慢”执行。 在更高的层面,它变得复杂。 C ++是一个很有用的工具,但通常是不恰当地作为所有问题的解决方案。 当我们使用最简单的语言来描述问题时,它会更好,有时候这是C ++的其他时间……汇编,操作码,解释语言。

C ++在很大程度上依赖于编译器“解释”意图,通过多次迭代爬行模板,类,宏等多层。 通过翻译的每个循环都有可能遇到意想不到的后果的规律 。 据我所知,处理器没有本地处理C ++构造的寄存器或操作码,因此每个都必须细分为简化部分。 在这个领域,编译器和代码标准是王道。 在某些情况下,它是教授三年级学生(处理器)的数学博士(编译器)的哲学等价物。

我喜欢C ++并保守地使用它,但多年来我几乎没有看到它写得很好。 我想强迫一些人看一下最终由构建反刍的程序集或机器代码,直到他们理解它是多么复杂。 坏C是一回事,糟糕的C ++可能会呈指数级恶化。

面试的更好答案……“你的团队什么时候才能看到C ++不是问题的答案?”

C ++中的大多数function都是解决C中(潜在)问题的解决方案(例如:构造函数,以确保创建的数据包的有效性(C中的struct

这意味着要在C中编写一个试图避免出现C ++特性问题的正确程序,您将不得不执行C ++在幕后执行的类似操作。 这导致两种情况下的类似性能。

当然,您总是可以编写“更快”的草率程序,但在所有情况下都无法正常工作

C有restrict ,C ++没有,尽管大多数编译器都将它作为扩展。

还有C ++没有的可变长度数组。

还有更好的想法? 任何帮助将不胜感激。

C ++中的STL很少比C中的特殊编码等效项慢。但是,STL的便利性有时会导致编写较慢的代码。 例如,假设一组固定的100个项目,其中的变量选择为10或15。 假设程序的时间关键循环多次询问是否已选择项目i 。 支持这种时间关键循环的快速数据结构将是100个bool的arrays(或矢量等)。 但是,填充std::set在C ++中编码可能比填充数组更容易。 出于这个原因,C ++程序员可能更喜欢数组上的集合。

当然,较慢的代码是否是一个问题取决于时间关键循环将看到多少服务。 如果对arrays技术进行编程需要额外的半小时,并且在程序的整个生命周期内节省的总执行时间为0.5秒,则设置技术可能更可取。 另一方面,如果总执行时间节省是30天,则arrays技术可能是优选的。

可以给出许多类似的答案。 祝你的面试顺利。

先验不是性能问题,但LLVM代码库既不使用RTTI也不使用exception,因为它们在代码大小方面被认为代价太高 。