Здравствуйте, Евгений Музыченко, Вы писали:

S>>ХЗ, я без понятия что такое "типичный современный прикладной проект". А вы, уверен, понимаете в этом еще меньше.

ЕМ>А я ХЗ, как можно понимать "еще меньше", чем "без понятия"

Ну т.е. вообще. Совершенно. Меньше, чем абсолютный ноль.

ЕМ>Это что-то очень редкое и нишевое.

А софт на C++ сейчас -- это что-то очень редкое и нишевое по сравнению с тем, сколько всего пишется на Java, С#, Go, Python, JavaScript.

ЕМ>Глядя на массовый софт

На какой именно?
Например, под Windows у меня из нативного в основном используются: Chrome, Telegram, MS Word и Excel, Lightroom (правда, старый, 5-й версии еще), foobar2000. Ничего из этого не тормозит. Тормоза Chrome, как я понимаю, JavaScript-ом определяются.

Иногда приходится запускать VisualStudio, та да, тормоз еще тот, но ведь она на C#.

S>>Удивительно, и как же на Ada разрабатывают mission critical софт, да еще и в embedded-е...

ЕМ>Точно "на Ada", или таки на "специальных реализациях Ada"?

На Ada под конкретную платформу.

ЕМ>Которые еще и нелегко перенести на другие платформы?

А вы много специфичного для конкретной платформы C++ного кода на совершенно другие платформы переносили?
Это я к тому, что если вы некие требования к Ada предъявляете, то подходите с той же линейкой и к C++.

S>>Может быть потому, что Ada допускает расширения для конкретных реализаций:

ЕМ>А языки, документация по которым этого не допускает, по-другому реализовать нельзя?

Мы все еще про стандарт?

ЕМ>Так-то и в реализациях BASIC/Pascal под всякими CP/M и подобными системами, вполне себе есть операции с портами ввода/вывода и произвольными адресами памяти, но сами те системы почему-то не стремились писать на этих языках.

Может мозги включите (если найдете) и подумаете, почему при наличии такого замечательного чистого Си ту же CP/M пришлось для дохлых персоналок того времени писать на Asm. Upd: Оказывается, там не только Asm, там еще и какой-то PL/M. Но Си нет.

S>>Просто потому, что Ada создавалась как универсальный язык для разработки софта для военных. И долгое время был единственным языком, разрешенным для использования в аэро- и космической отрасли.

ЕМ>Может быть, потому, что главной целью ставилась высокая надежность, а не эффективность?

Да-да-да, так и было. Людям нужно было hard-real time для космических ракет делать, а они на эффективность даже не обращали внимания.

S>>Так блин, там же Java (Java, Карл!) в 16KiB ворочалась. Да, это не та Java, которая JavaSE, но все-таки и не Си.

ЕМ>Во-вторых, что там было реализовано из той Java? Можно было запустить там любую программу на Java? Если нет, то нужно оценивать не по самому факту, а по функциональности реализованного подмножества.

Дяденька, вы дурку включаете специально когда на RSDN пишете? Если не слышали про Java Micro Edition, то погулили бы сперва.

Хотя, если вы всерьез думаете, что на Ada нет указателей на функции, даже при наличии свободного доступа к Гуглу и другим поисковикам, то что уж от вас ожидать, кроме очередной тупизины.

S>>А вы в курсе, что в этом случае вы имеете дело с нестандартным C++

ЕМ>Разумеется. Но дело-то в том, что сами языки C/C++ построены так, что компактные реализации отсекают лишь специфические элементы, вроде обработки исключений, операций с файлами, процессами и подобным, почти никогда не затрагивая базовых элементов языка.

Еще раз для альтернативно одаренных: когда вы от C++ что-то отсекаете (вроде обработки исключений), вы оказываетесь вне текущего стандарта. И зависите от того, что дает вам некая реализация. Это вас устраивает.

А вот когда на конкретной платформе конкретная реализация Ada предоставляет вам типы данных, заточенные под платформу, но не описанные в стандарте Ada, то вы заявляется о том, что это все нестандарт и как же после этого портировать Ada код на другие платформы.

Браво.

А скажите, пожалуйста, поборник C++ного стандарта, а где в стандарте C++ декларируется размерность char, short, int и long? В каком таком разделе указано, что эти типы соответствуют вашей "родной привязки к машинным типам данных (байт, часть слова, составное слово и т.п.)"?

S>>Что вы не имели дела с C++ными проектами хотя бы от 500KLOC и хотя бы от 10 человек.

ЕМ>С человеками понятно — я не люблю работать сообща, а что принципиально изменится, если я таки наваяю проект в полмиллиона строк?

У вас появится проблема большого объема кода. Как минимум. Впрочем, попробуйте, может что-то узнаете.

S>>вы не осознаете зачем и где нужны все те ругаемые вами фичи C++.

ЕМ>Какие именно? Я последовательно и регулярно ругаю только те фичи C++ (или отсутствие оных), которые создают неудобства в работе с проектами любого объема, и которые оправдываются лишь тем, что она достаточно больших проектах они начинают приносить больше пользы, чем вреда.

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

catch(const std::exception & x) {
  log("initialization failure: %s", x.what());
}

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

В показанном коде обнаружилась проблема -- когда задается `%s`, то параметр ожидается как wide-string, тогда как x.what() возвращает narrow-string.

Компилятор это пропустил. Неприятно, но не страшно.
Меняем на:

catch(const std::exception & x) {
  log("initialization failure: %s", make_wide_string(x.what()));
}

Но тут новый УПС!
Оказывается, нужно передавать именно `const wchar_t*`, а не std::wstring.
Так что пришлось еще раз исправлять:

catch(const std::exception & x) {
  log("initialization failure: %s", make_wide_string(x.what()).c_str());
}

И это мне еще повезло обратить внимание на кракозябры в логе. А сколько еще по проекту таких граблей раскидано?

Все это на фоне того, что предоставляют spdlog и fmtlib на современном C++ с проверками форматной строки и параметров еще в compile-time.

Так что для вас сложные шаблоны и пихание этих самых шаблонов во все дыры может быть и выглядит чрезмерным усложнением, а в проектах, где работают совместно разные люди, эти все возможности (будучи использованы правильно), защищают от кучи ошибок разной степени тяжести.

ЕМ>До сих пор никто не показал, что это был единственный возможный путь развития языка, и нужные фичи нельзя было реализовать так, чтоб они не создавали проблем без нужды.

C++ -- это результат естественной эволюции. Он получился таким, каким получился. Так уж вышло.

Если вы требуете каких-то доказательств что это была "правильная" эволюция, "единственно возможная" и все такое прочее, то вы просто в очередной раз демонстрируете свою альтернативную одаренность.