История изменений
Исправление eao197, (текущая версия) :
Это не троллинг, меня интересует именно технические особенности.
Без привязки к конкретной задаче это как раз и выглядит как троллинг. Ибо есть факторы, которые могут склонять чашу весов в ту или иную сторону. Например, конструкторы/деструкторы могут добавлять оверхед по сравнению с C. А шаблоны, напротив, выигрывать за счет генерации кода, оптимального под конкретные структуры данных (Страуструп давно приводит пример, как шаблонный std::sort выигрывает у С-шного qsort). Даже исключения, в зависимости от того, как они используются, могут давать либо выигрыш, либо проигрыш.
Нужно везде, где можно использовать передачу по указателю или ссылке (собственно, если в Си делать memmove при передаче структуры в качестве аргумента, то это вызовет примерно такой же оверхед, как дефолтный конструктор копирования С++. Верно?).
Далеко не всегда. Если объекты «легкие», то передача их по значению может приводить к увеличению производительности из-за лучшей локальности данных.
Исходная версия eao197, :
Это не троллинг, меня интересует именно технические особенности.
Без привязки к конкретной задаче это как раз и выглядит как троллинг. Ибо есть факторы, которые могут склонять чашу весов в ту или иную сторону. Например, конструкторы/деструкторы могут добавлять оверхед по сравнению с C. А шаблоны, напротив, выигрывать за счет генерации кода, оптимального под конкретные структуры данных (Страуструп давно приводит пример, как шаблонный std::sort выигрывает у С-шного qsort). Даже исключения, в зависимости от того, как они используются, могут давать либо выигрыш, либо проигрыш.
Нужно везде, где можно использовать передачу по указателю или ссылке (собственно, если в Си делать memmove при передаче структуры в качестве аргумента, то это вызовет примерно такой же оверхед, как дефолтный конструктор копирования С++. Верно?).
Далеко не всегда. Если объекты «легкие», то передача из по значению может приводить к увеличению производительности из-за лучшей локальности данных.