Не так уж много плохого я могу сказать о C++. В конце-концов я не могу быть объективным по отношению к языку, который был моим любимым языком программирования более десяти лет.

Возможно, что перечисленные мной проблемы C++ для кого-то покажутся несерьезными. И, очень вероятно, что у многих будет собственный список проблемных мест в C++. Ну что ж -- сколько людей, столько и мнений. Я всего лишь описываю то, что напрягает лично меня.

Проблемы C++ можно условно разделить на технические и политические. Хотя политические являются следствием технических. Часть проблем описана в причинах поиска нового языка. Здесь я укажу еще несколько.

Отсутствие безопасного режима

Иногда очень хочется иметь возможность компилировать C++ в "безопасном" режиме, с контролем корректности индексов и указателей, с печатью полного stack trace при обнаружении каких-либо проблем.

Конечно, существуют очень требовательные к эффективности программы, которые выжимают биты из тактов и в которых проверка корректности указателя непозволительная роскошь. Но мне уже давно не приходилось сталкиваться с подобными случаями. А вот выяснять, почему проработавший несколько месяцев сервер вдруг свалился в результате Access Violation или Segmentaion Fault приходилось. Думаю, что помощь безопасного режима здесь оказалась бы не лишней.

Вот чего я не понимаю, так это почему никто из монстров софтостроения (Microsoft, IBM, HP и др.) не вложились в разработку виртуальной машины для C++. Компилятору-то все равно, производит ли он нативный x86 или SPARC код или инструкции виртуальной машины. Такая "песочница" для C++ позволила бы в безопасном режиме использовать миллионы строк унаследованного C++ кода. Что-то подобное, насколько мне известно, пытались сделать в CERN с помощью проекта CInt.

Исключения

В самом начале исключений в C++ не было. Затем поддержка исключений появлялась в разных компиляторах в разное время. Затем появился стандартный класс std::exception в качестве базового для всех исключений.

Все это привело к тому, что разные C++ библиотеки используют разные подходы к диагностированию и обработке ошибок. Чем более старая и портабельная библиотека, тем больше вероятность, что исключения в ней не используются вообще. А то, что в языке в качестве исключения можно выбрасывать все, что угодно (хоть int) приводит к тому, что не все используют стандартную иерархию исключений, основанную на std::exception.

Из-за этого при разработке C++ с применением разных библиотек приходится использовать в коде разные подходы к обработке ошибок. Это утомительно. К тому же на фоне современных языков это еще и выглядит напрасной тратой времени.

Метапрограммирование на шаблонах и Boost-изация C++ стиля

Механизм шаблонов (вкупе с RAII и деструкторами) является тем якорем, который до сих пор удерживает (и, вероятно, еще долго будет удерживать) меня в C++. Только в D появилась достойная замена шаблонам C++.

Тем не менее, многие качества шаблонов явились всего лишь побочным явлением их дизайна. В частности метапрограммирование на шаблонах. Мне кажется это ненормальным. Либо шаблоны нужно было ограничить, либо расширить так, чтобы не нужно было писать вагоны кода для создания класса IsFunction или FunctionReturnType. Ничего подобного благодоря затянутым процедурам стандартизации языка не произошло.

В результате для C++ программистов шаблоны стали каким-то способом доказательства собственной крутизны. Яркие примеры чего можно найти внутри Boost-а.

Я просто не считаю нормальным необходимость писать сотни строк шаблонного кода для того, чтобы обойти органичения стандарта языка и дыры в его реализациях. Чтобы в результате получить решения, в которых способны разобраться избранные продвинутые C++ники.

Длительное время компиляции

Стоит добавить в проект пару-тройку шаблонных классов и использовать STL, как время компиляции увеличивается чуть ли не на порядок. По сравнению со скоростью компиляции того же D или даже Java скорость компиляции C++ оказывается слишком, слишком медленной.

Библиотеки: зоопарк и отсутствие

Следствием того, что язык C++ никогда не имел большой стандартной библиотеки и при этом развивался в течении длительного времени (имеется в виду добавление в язык шаблонов и исключений) стало наличие целого зоопарка библиотек для выполнения одних и тех же действий. Например, только для GUI можно вспомнить Qt, wxWidgets, FOX Toolkit и Fltk (не считая переодически возникающих молодых конкурентов). Аналогичная картина для работы с XML. Аналогично для системных средств (т.к. многопоточность, файловая система, IPC): ACE, POCO, Boost, Qt.

Все это сопровождается разными подходами к управлению памятью и информированием об ошибках. Так, Qt и FOX Toolkit навязывают разработчику собственную политику использования памяти. POCO выбрасывает исключения для информирования об ошибках, в то время как ACE использует коды возврата и errno.

При этом иногда найти хорошую, кросс-платформенную C++ библиотеку для каких-то целей оказывается слишком сложно. Как, например, в случае с поддержкой SOAP.