Вычислительная производительность

Результирующий объём исполнимого кода 

Использование шаблонов C++ представляет собой параметрический полиморфизм на уровне исходного кода, но при трансляции он превращается в ситуативный (ad hoc) полиморфизм (то есть перегрузку функций), что приводит к существенному увеличению объёма машинного кода в сравнении с языками, имеющими истинно полиморфную систему типов (потомками ML). Для снижения размера машинного кода пытаются автоматически обрабатывать исходный код до этапа раскрутки шаблонов^[23][24]. Другим решением могла бы быть стандартизованная ещё в 1998 году возможность экспорта шаблонов, но она доступна далеко не во всех компиляторах, так как её трудно реализовать^{[25][26][мнения 4]} и для импорта библиотек шаблонов С++ в языки с существенно отличной от С++ семантикой она всё равно была бы бесполезна. Сторонники С++ оспаривают масштабы раздувания кода как преувеличенные^[27], игнорируя даже тот факт, что в Си параметрический полиморфизм транслируется непосредственно, то есть без дублирования тел функций вообще. При этом сторонники С++ считают, что параметрический полиморфизм в Си опасен — то есть более опасен, чем переход от Си к С++ (противники С++ утверждают обратное — см. выше).

Потенциал к оптимизации 

Из-за слабой системы типов и изобилия побочных эффектов становится крайне затруднительным эквивалентное преобразование программ, а значит и встраивание в компилятор многих важных оптимизирующих алгоритмов — автоматического распараллеливания, устранения ненужных промежуточных представлений данных и вычислений, лямбда-лифтинга, вызовов процедур с передачей продолжений, суперкомпиляции и др. В результате реальная эффективность программ на С++ ограничивается имеющейся квалификацией программистов и вложенными в конкретный проект усилиями, и «небрежная» реализация может существенно уступать по эффективности «небрежным» реализациям на языках более высокого уровня, что подтверждается сравнительными испытаниями языков^[28]. Это является существенным препятствием против применения С++ в индустрии data mining.

Эффективное управление памятью 

Потенциал к повышению эффективности управления памятью весьма ограничен. Хотя существуют многочисленные реализации автоматической сборки мусора, использование более эффективных способов управления памятью (таких как статический вывод регионов) для конкретной библиотеки невозможно (точнее, это привело бы к реализации поверх языка С++ интерпретатора нового языка, сильно отличающегося от С++ как большинством объективных свойств, так и общей идеологией) по причине необходимости прямого доступа к AST. Для автоматического управления памятью в С++ традиционно используются т. н. «умные указатели», которые в определенных условиях могут иметь худшую временную сложность, чем сборка мусора^{[пояснения 6]}. Ручное же управление памятью значительно снижает эффективность самих программистов (см. раздел Результативность).

Замедление Си 

В условиях узко ограниченных вычислительных ресурсов (например, при программировании многих встраиваемых систем) неприемлемыми могут оказаться самые разные аспекты С++, отличающие его от Си. Механизм виртуальных функций реализуется посредством позднего связывания, то есть требует динамического вычисления реального адреса функции (RVA). Ещё более существенные накладные расходы возникают в связи с созданием временных объектов при передаче параметров в функции и возврате (использование конструктора копирования). То есть простая адаптация программы на Си под идеологию С++ уже вызывает замедление, которое в определённых условиях может оказаться недопустимым. Наконец, встраиваемая система может просто не располагать тем объёмом памяти, который необходим для библиотеки времени исполнения (RTL), сопровождающей любую программу на С++. Хотя формально стандарт не накладывает ограничения на состав этой библиотеки для конкретной программы на С++, при полном её удалении уже нельзя говорить об использовании языка С++ в качестве инструмента, так как конструкции языка, связанные с RTL, окажутся утраченными (даже операции new/delete и new[]/delete[]) — соответственно будет отличаться и идеология программирования (несвязанные с RTL возможности - шаблоны, более строгая типизация и т.п. - останутся).