Избыточные и опасные возможности

Гарантия некорректности

Из-за слабой системы типов программист оказывается волен легко нарушить заданную в конкретном случае дисциплину программирования. Например, хотя модификатор const предназначен для повышения предсказуемости поведения (что должно облегчить доказательство корректности, и, как следствие, расширить возможности оптимизации), но модификатор mutable предназначен именно для принудительного разрешения изменения состояния внутри константного объекта. Это значит, что код сторонней библиотеки на С++ может содержать изменяемое состояние вопреки любым попыткам назначить ему извне свойство константности. Более того, допускается динамически удалить атрибут const с константного объекта, превращая его в леводопустимый (L-value). В частности, совершенно корректной с т.з. семантики языка является команда присваивания

const_cast< имя_класса* >(this) = NULL;

— хотя она однозначно приводит к фатальной ошибке времени исполнения на нижеследующей команде. Сама по себе явная декларация в спецификации языка подобных возможностей делает попытки формальной верификации бессмысленными.

Неконтролируемая макроподстановка

Средства макроподстановки Си (#define) являются сколь мощным, столь же опасным средством. Они сохранены в C++ несмотря на то, что для решения всех^{[ источник? ]} задач, для которых они были предусмотрены в Си, в С++ были предоставлены более строгие и специализированные средства — шаблоны, перегрузка функций, inline-функции, пространства имён, более развитая типизация, расширение применения модификатора const, и др. В унаследованных от Си стандартных библиотеках много потенциально опасных макросов^[22]. Шаблонное метапрограммирование также порой совмещается с использованием макроподстановки для обеспечения т. н. «синтаксического сахара».

Неэкономная экономия

В контексте задач, для решения которых разработан Си, считается опасным расширение его до С++, и не только из-за искажения имён (name mangling), увеличения библиотеки времени исполнения (RTL) и раздувания кода использованием шаблонов (см. раздел Вычислительная производительность), но в большей степени из-за присущей С++ идеологии программирования. Из того, что Си является подмножеством С++, вообще говоря, не следует, что С++ должен быть однозначно лучше, чем Си; и противники С++ утверждают, что в данном случае расширение возможностей системы привело к серьёзному ухудшению её свойств. Например, Линус Торвальдс придерживается такого мнения:

С++ — кошмарный язык. Его делает ещё более кошмарным тот факт, что множество недостаточно грамотных программистов используют его, до такой степени, что оказывается намного проще выкинуть его как мусор. Откровенно говоря, даже если нет *никаких* причин для выбора Си, кроме того чтобы держать С++-программистов подальше — то одно это уже будет достаточно веским основанием для использования Си.
…Я пришёл к выводу, что *действительно* предпочту выгнать любого, кто предпочтёт вести разработку проекта на С++, нежели на Си, чтобы этот человек не загубил проект, в который я вовлечён.
С++ приводит к очень, очень плохим проектным решениям. Неизбежно начинают применяться «замечательные» библиотечные возможности вроде STL, и Boost, и прочего мусора, которые могут «помочь» программированию, но порождают:
— невыносимую боль, когда они не работают (и всякий, кто утверждает, что STL и особенно Boost стабильны и портируемы, настолько погряз во лжи, что это даже не смешно)
— неэффективно абстрагированные программные модели, когда спустя два года обнаруживается, что какая-то абстракция была недостаточно эффективна, но теперь весь код зависит ото всех окружающих её замечательных объектных моделей, и её нельзя исправить, не переписав всё приложение.
Другими словами, единственный способ иметь хороший, эффективный, низкоуровневый и портируемый С++ сводится к тому, чтобы ограничиться всеми теми вещами, которые элементарно доступны в Си. А ограничение проекта рамками Си будет означать, что люди его не выкинут, и что будет доступно множество программистов, действительно хорошо понимающих низкоуровневые особенности и не отказывающихся от них из-за идиотской ерунды про «объектные модели».
… когда эффективность является первостепенным требованием, «преимущества» С++ будут огромной ошибкой.

— Линус Торвальдс, ^{[мнения 3]}

Более эффективными и качественными инструментами в этой сфере могут быть другие потомки Си (см. раздел Влияние и альтернативы).