Вместо того, чтобы привести аргументы в ответ на конкретные претензии, выдвинутые в оригинальной статье, автор восхваляет деструкторы. Деструкторы - это конечно хорошо, что и без них неплохо! Например, в Джава их нет - и ничего, живут как-то. Попробую и я себя на поприще С++ и прокомментирую конкретные пункты, приведенные автором.
"Согласно книге The Design and Evolution of C++, язык C++ был создан Страустропом, как «C для крупных проектов». Однако практика показывает, что на C вполне успешно разрабатываются очень даже крупные проекты. " Книга вышла в 1994 году. На дворе 2016. С момента написания этой книги вышли 4 стандарта языка С++ (и пятый на подходе), так что хотя книга имеет бесспорное историческое значение, я бы не воспринимал ее как истину в последней инстанции применительно к текущему состоянию дел. И хотя на С, безусловно, можно разрабатывать крупные проекты, известные мне новые крупные проекты для мейнстримных платформ все-таки разрабатывают на С++ (а не на С, другие языки не рассматриваем). Единственное известное мне исключение - системное программирование, где для того есть вполне легитимные причины.
"Лямбды и прочие ништяки не всегда получается использовать на работе, так как о C++11 там только мечтают. К сожалению, многие реальные проекты на C++ в наше время — это страшный легаси с C++98..." Анекдоты очень трудно оспорить, а реальной статистики нет. Тем не менее, согласно моим наблюдениям, С++11 на настоящее время - стандарт, и требования знакомства с С++11 пристутствуют во всех объявлениях о наборе программистов на работу, которые попадаются мне на глаза.
"Сложность кода. Если вы видели код на C++, реальный, а не из учебника, то знаете, что он часто он оказывается действительно очень непрост для восприятия." Сложность - это вообще очень сложное понятие. Вспоминается, как на мое замечание касательно одной из песен Несчастного Случая, в которой заявляется, что "...0.5, 0.7, 0.33 - простые числа...", в котором я указал на то, что приведенные числа по определению не являются простыми, мне возразили - "Да чего же в них сложного-то!". Правильнее говорить о пороге вхождения, и трудно возразить, что попрог вхождения в С++ выше, чем в С. Более того, определенная часть сложности С++ - искусственная, без которой вполне можно было бы обойтись. (Определенная, к сожалению, обусловлена его неотъемлимыми характеристиками). Впрочем, как раз вопрос сложности был отражен в статье-возражении, так что я по этому пункту ничего добавлять не буду. Хотя, нет, скажу, что приведенный пример - это действительно пример плохого кода. Но виноват в этом не С++.
"Пример со стримами хорошо иллюстрирует, что C++ — словно вирус. Все начинается с использования какой-то одной маленькой его возможности, и через какое-то время весь проект кишит лямбдами, шаблонами и вот этим всем, и в этом уже никто не может нормально разобраться..." Пример неудачный. Во-первых, стримы в С++ - это наша боль. Мы их не любим. Они полны недостатков. Не следует по стандартным стримам судить о всем С++. Во вторых, дальнейший текст просто не соответствует действительности. "Но вот проблема — все private поля объявляются в .hpp файле и при изменении приводят к перекомпиляции половины проекта (в C такой проблемы с инкапсуляцией нет совсем)" Почему это? Изменение полей в С-структуре точно так же приведет к необходимости перекомпиляции всего проекта. "А затем еще правильно перегрузить оператор присваивания, реализовать конструктор перемещения, и чтобы при этом все это добро правильно работало с STL…"Я очень не люблю идиому Прыщик (sic!), но никаких специальных действий вроде описанных выше она не требует. std::unique_ptr<impl> pimpl; - это все, что требуется от отца русской демократии в 99.99% случаев. "Аналогично вы не можете использовать исключения, не обернув все в умные указатели, которые, напомню, являются классами и используют шаблоны, а чтобы кода было поменьше, придется еще использовать и auto." Это, простите меня, бессмысленный набор слов. Да, в современном С++ широко используются умные указатели, независимо от присутствия исключений, и таковые умники, очевидно, являются классами и шаблонами - но зачем так говорить, как будто это что-то плохое? Это что-то хорошее, к тому же, при правильном использовании, с zero overhead (не знаю, как сказать по-русски). "Аналогично вы не можете использовать классы и конструкторы, не используя исключения, так как нормально вернуть ошибку из конструктора можно только бросив исключение. "Я не знаю, что понимается под словом нормально, но способы вообще-то есть. Те же бедные стримы как-то худо-бедно справляются.
"ООП. Кажется, сегодня уже вся индустрия осознала, что объединение кода и данных — идея так себе, не говоря уже про повсеместное использование наследования." Ну я вам не скажу за всю
"STL часто преподносится так, словно в мире С нет библиотек с готовыми алгоритмами и контейнерами, что, разумеется, не так." Что, разумеется, не так. Это я о том, что STL так не преподносится. STL предподносится как (и является) стандартной библиотекой, включенной в реализацию языка. Библиотекой весьма полезной, и, за редкими исключениями (вроде vector<bool>) хорошо продуманной. Более того, контейнеры и алгоритмы являются взаимонезависимыми, что позволяет сочетать разные реализации друг с другом - например, алгоритмы STL прекрасно работают с бустовскими контейнерами. "Например, если вы знаете что-то о природе данных, которые хранятся в контейнере, то можете опустить некоторые проверки. " Например, какие? Не понятно.
"Из-за повсеместного использования шаблонов скорость компиляции кода на С++ просто ни на что не годится. Не говоря уже о том, что при компиляции крупных проектов нередко может потребоваться, скажем, гигов 10 оперативной памяти." Ну да, компиляция С++ кода - дело иногда небыстрое. Минут 20 можно компилировать большой проект. Ну вот как-то не вижу я это такой уж сильной проблемой, да и инкрементальная компиляция помогает. Да, может потребоваться 10 гигов. Может и 20. Но у нас, напомню, идет 2016, заканчивается уже можно сказать. Как-нибудь осилим 20 гигов, а?
"Как уже отмечалось, если вы берете исключения, то будьте готовы использовать для всего RAII и смартпоинтеры, а следовательно и тормозить, когда счетчики ссылок обнуляются." Ну это банальная некомпетентность. Во-первых, RAII уже давно переименовали в SBRM, а во-вторых, как я писал выше, std::unique_ptr обладает zero overhead по сравнению с ручным управлением памятью по производительности. "Не удивительно, что в том же Google в коде на С++ исключения не используются" Да. Google Coding Guidelines suck, и это все знают. Смотри https://www.linkedin.com/pulse/20140503193653-3046051-why-google-style-guide-for-c-is-a-deal-breaker.
"По своему опыту могу сказать, что отлаживать код C++ — мягко говоря, удовольствие ниже среднего. " А вот с этим я склонен согласиться. Отлаживать код - удовольствие ниже среднего. Именнно по-этому мной и единомышленниками давным-давно принято решение писать код без багов. Проведенный анализ показал, что привнесение багов в код не приносит никаких преимуществ, и создает массу недобств - так что мы решили, что мы отказываемся от багов в коде. "Попробуйте, это правда не сложно." Именно это я и хотел сказать, да.
"Код на C прекрасно пишется без каких-либо тяжеловесных IDE, в обычном Sublime Text или Vim с ctags. " Согласен. А код на С++ прекрасно пишется в обычном Vim с YouCompleteMe. Опять имеем дело с банальным не владением ситуацией.
"Нельзя упускать из виду и кадровый вопрос..." А это хорошо! Чем меньше народу владеет средством - тем лучше тем, кто им владеет. По весьма очевидным причинам. Так что это аргумент за С++, а не против.
"Ну и до кучи. (1) Далеко не везде есть компилятор C++, особенно если это какой-нибудь C++11/14/17". Ага. Это правда. Ну так ведь и сишный компилятор не везде есть. Если приходится писать код для телевизоров, то скорее уж Джава.
Заключение. Приходится признать, что автор мало знаком с современным С++ и состоянием дел в области. И хотя в языке С++ достаточно реальных проблем, ни одна из них не была отражена в статье, что сводит ее практическую ценность к нулю.
