Какое снижение производительности оператора перегрузки STL

Question

Мне очень нравится STL. Это делает алгоритмы кодирования очень удобными, поскольку предоставляет вам все примитивы, такие как parition, find, binary_search, итераторы, priority_queue и т. Д. Кроме того, вам вообще не нужно беспокоиться об утечках памяти.

Мое единственное беспокойство вызывает снижение производительности при перегрузке оператора, которое необходимо для работы STL. Для сравнения я полагаю, что == обеспечивает необходимую семантику. Нам нужно перегрузить оператор ==, если мы добавляем наши классы в контейнер.

Какую эффективность я теряю для этого удобства?

Еще один вопрос, касающийся утечек памяти:

1. Может ли произойти утечка памяти при использовании контейнеров STL?
2. Может ли утечка памяти случиться в Java?

Answer 1

При использовании алгоритмов stl для универсальных типов вам необходимо каким-то образом предоставить логику сравнения. Перегрузка оператора не снижает производительность по сравнению с любой другой функцией и может (как и любая другая функция) быть встроенной для удаления любых издержек вызова функции.

Многие стандартные контейнеры и алгоритмы также используют std::less и, следовательно, по умолчанию < вместо ==.

Стандартные контейнеры сами по себе не протекают, но вы можете использовать их для хранения объектов (например, указателей), которые не обязательно очищают память, которую они "владеют".

Трудно утечь память в Java, но это не значит, что вы не можете попасть в неприятности, не имея хорошей семантики владения объектом, и это не значит, что вы не можете использовать всю доступную память авария.

Answer 2

Я оставлю ответы C ++ на предыдущие постеры, но на 100% да, вы можете утечь память в Java. Его тоже очень трудно найти, если у вас нет хороших инструментов для профилирования памяти. В общем, утечки памяти в языках с автоматической сборкой мусора (например, Java, Python и т. Д.) Происходят, когда вы неоднократно создаете экземпляры объектов, но либо A. не очищает их, когда вы закончили с ними (например, вызываете «close» в подключение к базе данных) или B. продолжают сохранять другие объекты, которые указывают на них (например, Hashtables), так что автоматический сборщик мусора никогда не сможет собирать их.

Если ваше приложение находится в том состоянии, которое, по вашему мнению, должно быть стабильным, и вы получаете один из следующих вариантов:

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

Тебе предстоит отладка;)

Answer 3

Мое единственное беспокойство вызывает снижение производительности при перегрузке оператора, которое необходимо для работы STL. Для сравнения я полагаю, что == обеспечивает необходимую семантику. Нам нужно перегрузить оператор ==, если мы добавляем наши классы в контейнер.

Это не существует. Ваш перегруженный оператор реализован как вызов функции. И если вы не перегружаете оператор, вам нужно определить функцию для использования вместо этого. Таким образом, производительность точно такая же, только с более чистым синтаксисом.

Answer 4

«Штраф» на самом деле бонус.

Давайте рассмотрим наиболее типичные алгоритмы сортировки. C не имеет перегрузки оператора. В результате qsort получает указатель на функцию. Каждое сравнение использует косвенный вызов функции (во время выполнения). C ++ имеет перегрузку операторов. Для std::sort каждое сравнение является прямым вызовом (фиксируется компоновщиком) или встроенным (компилятором). Это намного эффективнее. std::sort нередко бывает в 6 раз быстрее, чем qsort.

В общем случае, перегрузка операторов значительно упрощает выражение функций «по умолчанию» для типа таким образом, который может быть использован другим кодом и компиляторами. Альтернативы гораздо менее эффективны. Либо они полагаются на макросы (которые вредят программистам), либо они полагаются на указатели функций (которые вредят оптимизаторам и процессорам).

Answer 5

Поскольку перегрузка оператора просто приводит к вызову функции, и вам придется написать функцию для выполнения работы в любом случае, накладные расходы равны нулю. Перегрузка операторов - это просто удобство, поэтому вы можете делать что-то вроде x == y вместо x.equals (y) или x

Answer 6

Какое снижение производительности при перегрузке оператора STL

В дополнение к этому вы всегда можете подключить своих операторов, это даже не повлечет за собой штраф за вызов функции.