运算符重载 STL 的性能损失是什么

发布于 2024-08-12 16:06:09 字数 307 浏览 2 评论 0 原文

我非常喜欢STL。它使编码算法非常方便,因为它为您提供了所有原语,如分区、查找、binary_search、迭代器、priority_queue 等。此外,您根本不必担心内存泄漏。

我唯一担心的是操作符重载的性能损失,这是使 STL 工作所必需的。 为了进行比较,我认为它依赖于 == 提供所需的语义。如果我们将类添加到容器中,我们需要重载 == 运算符。

为了这种便利,我损失了多少效率?

另一个关于内存泄漏的问题:

  1. 使用 STL 容器时会发生内存泄漏吗?
  2. Java 中会发生内存泄漏吗?

I like STL a lot. It makes coding algorithms very convenient since it provides you will all the primitives like parition, find, binary_search, iterators, priority_queue etc. Plus you dont have to worry about memory leaks at all.

My only concern is the performance penalty of operator overloading that is necessary to get STL working.
For comparison, I think it relies that == provides the needed semantics. We need to overload ==operator if we are adding our classes to a container.

How much efficiency am I losing for this convenience?

Another aside question regarding memory leaks:

  1. Can memory leak ever happen when using STL containers?
  2. Can a memory leak ever happen in Java?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

溺孤伤于心 2024-08-19 16:06:09

在泛型类型上使用 stl 算法时,您必须以某种方式提供比较逻辑。与任何其他函数相比,运算符重载不会造成性能损失,并且可以(像任何其他函数一样)内联以消除任何函数调用开销。

许多标准容器和算法也使用 std::less,因此默认情况下 < 而不是 ==

标准容器本身不会泄漏,但您可以使用它们来保存对象(例如指针),这些对象不一定会清理它们“拥有”的内存。

在java中泄漏内存是很困难的,但这并不意味着你不会因为没有良好的对象所有权语义而陷入麻烦,也不意味着你不能用完所有可用内存并崩溃。

When using stl algortithms on generic types, you have to supply the comparison logic in some way. Operator overloading has no performance penalty over any other function and may (like any other function) be inlined to remove any function call overhead.

Many standard containers and algorithms also use std::less and hence by default < rather than ==.

The standard containers don't themselves leak, but you can use them to hold objects (such as pointers) which don't necessarily clean up memory that they 'own'.

It's difficult to leak memory in java, but that doesn't mean you can't get into trouble by failing to have good object ownership semantics and it doesn't mean that you can't use up all the available memory and crash.

蓝咒 2024-08-19 16:06:09

我将把 C++ 答案留给之前的发帖者,但是 100% 是的,Java 中可能会出现内存泄漏。除非您有一些好的内存分析工具可供查看,否则它往往也很难找到。一般来说,自动垃圾收集语言(例如 Java、Python 等)中的内存泄漏发生在您重复实例化对象时,但是 A. 使用完对象后没有清理它们(例如,在对象上调用“close”)数据库连接)或 B. 继续保留指向它们的其他对象(例如哈希表),以便自动垃圾收集器永远无法对它们进行垃圾收集。

如果您的应用程序处于您认为应该稳定的状态,并且您会得到以下之一:

http://java.sun.com/javase/6/docs/api/java/lang/OutOfMemoryError.html

您正在进行一些有趣的调试;)

I'll leave the C++ answers to the previous posters, but 100% yes you can memory leak in Java. It tends to be really difficult to find too unless you have some good memory profiling tools to look at. In general, memory leaks in automated garbage collection languages (e.g. Java, Python, etc.) occur when you repeatedly instantiate objects, but either A. don't clean them up when you're done with them (e.g. calling "close" on a database connection) or B. continue to persist other objects that point to them (e.g. Hashtables) so that the automated garbage collector can never garbage collect them.

If your application is in what you think should be a stable state and you get one of these:

http://java.sun.com/javase/6/docs/api/java/lang/OutOfMemoryError.html

You're in for some fun debuggin ;)

窝囊感情。 2024-08-19 16:06:09

由于运算符重载只会导致函数调用,并且无论如何您都必须编写一个函数来完成这项工作,因此开销为零。运算符重载只是一种方便,因此您可以执行 x == y 之类的操作,而不是 x.equals(y) 或 x <; y 而不是 x.compaterTo(y)。编译器本质上生成类似: x.==(y) 或 x.<(y) (这不会编译,但你明白了)。

Since operator overloading simply results in a function call, and you would have to write a function to do the work anyways, the overhead is zero. Operator overloading is just a convenience so you can do things like x == y instead of x.equals(y) or x < y instead of x.compaterTo(y). The compiler essentially generates something like: x.==(y) or x.<(y) (that won't compile, but you get the idea).

回忆凄美了谁 2024-08-19 16:06:09

“惩罚”实际上是一种奖励。

让我们以最典型的算法为例:排序。 C 没有运算符重载。因此,qsort 采用函数指针。每次比较都使用间接函数调用(在运行时)。 C++确实有运算符重载。对于std::sort,每次比较都是直接调用(由链接器修复)或内联(由编译器)。这是非常有效的。 std::sortqsort 快 6 倍的情况并不少见。

一般来说,运算符重载使表达类型的“默认”函数变得更加容易,并且可以被其他代码和编译器利用。其他替代方案的效率要低得多。它们要么依赖宏(这会伤害程序员),要么依赖函数指针(这会伤害优化器和 CPU)。

The "penalty" is actually a bonus.

Let's take the most typical of algorithms, sorting. C does not have operator overloading. As a result, qsort takes a function pointer. Each comparison uses an indirect function call (at runtime). C++ does have operator overloading. For std::sort, each comparison is a direct call (fixed by linker) or inlined (by compiler). This is far mroe effective. It's not uncommon for std::sort to be 6 times faster than qsort.

In general, operator overloading makes it a lot easier to express the "default" functions for a type, in a way that can be exploited by other code and compilers. The alternatives are far less efficient. Either they rely on macros (which hurt programmers) or they rely on function pointers (which hurt optimizers and CPUs.)

狼亦尘 2024-08-19 16:06:09

我唯一担心的是操作符重载的性能损失,这是使 STL 工作所必需的。为了进行比较,我认为它依赖于 == 提供所需的语义。如果我们将类添加到容器中,我们需要重载 == 运算符。

这是不存在的。您的重载运算符是作为函数调用实现的。如果您没有重载该运算符,则需要定义一个函数来代替。因此,性能完全相同,只是语法更简洁。

My only concern is the performance penalty of operator overloading that is necessary to get STL working. For comparison, I think it relies that == provides the needed semantics. We need to overload ==operator if we are adding our classes to a container.

It is nonexistent. Your overloaded operator is implemented as a function call. And if you didn't overload the operator, you'd need to define a function to use instead. So the performance is exactly the same, just with a cleaner syntax.

○闲身 2024-08-19 16:06:09

运算符重载 STL 的性能损失是什么< /a>

除此之外,您始终可以让运算符内联,这甚至不会受到函数调用的影响。

What is the performance penalty of operator overloading STL

In addition to this you can always have your operators inline this will not even have the penalty of a function call.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文