Здравствуйте, enji, Вы писали:

E>Что ты вообще имеешь в виду под усложнением синтаксиса в с++11/14?
Если в терминологии wikipedia{C++11}{C++14}:
lamda-выражения считаю бесполезными — если мне надо вызвать несколько функций, я их вызову.
Alternative function syntax — зачем?
User-defined literals — бесполезно.
Function return type deduction — ужас
Variable templates — бесполезно

E>она во многих отношениях слабее явы. До нелюбимого тобой с++11 там даже потоков не было... Что касается опций линковки — ты о чем?
Я и говорю, что во многих отношениях слабее явы. Если нужно собрать один и тот-же проект в разных дистрибутивах линукса, то процедуру сборки прийдется усложнять. Это проблема решаемая,
но все же она присутствует и средства сборки линукс не полностью интуитивны для программистов, которые не знают auto-tools или тонкости make. Потом, при сборке того же буста, в разных дистрибутивах часто возникают проблемы с заголовчными файлами.

E>Опять же, более сильная стандартная библиотека не взлетит на тех же мелких контроллерах. Все равно будут какие-то подмножества в каждой области применения.
Правильно — возможно, нужна еще одна, более полная библиотека, аналогичная библиотеке Java.

E>Чтобы расстрелять стек / кучу / etc, достаточно обратиться по мусорному указателю. С учетом отсутствия контроля со стороны рантайма, это сделать элементарно — неинициализированная переменная, дважды вызвали деструктор, вышли за границы массива, ...
Если программа дважды вызывает деструктор или обращается по мусорному указателю, то в ней баг и она работать не будет. Да, на C++ найти этот баг может быть несколько сложнее, но в больших проектах для этого можно использовать собственные менеджеры памяти и тот же valgrind(наверняка в Windows есть аналогичные средства). Да — проблемы с памятью в программах на С++ встречаются, но они решаемы, если программист понимает, что делает. Для этого всего то нужно потратить две недели-месяц на чтение книг по С++.

E>Умные указатели — это не сборщик мусора. Их надо осознанно использовать, обычные указатели никуда не деваются — т.е. есть риск ошибки, циклы разруливаются только руками — снова есть риск ошибки... Сравни это с явовской ссылкой — с ней что-то сделать не так уже значительно сложнее.
Та или иная система учета памяти в С++ была бы полезна. Но для этого не нужен сборщик мусора — система в Objective C достаточно удобна, есть и другие. И медленная VM для этого — перебор.

E>В смысле — в один exe склеены несколько файлов? Хз насчет Alpha, но win/lin в одном файле я что-то пока не видел А вот явовские софтины, запускающиеся и там и там — встречались
Да я тоже не встречал, как впрочем и живых Alpha процессоров. Наверное, достаточно распространять по бинарнику для каждой архитектуры.

E>Мы ж про бизнес-приложения? Тут безопасность рулит, а производительность — не принципиальна. Тут сбоку как раз темка про ява/с++, можешь там ознакомиться
Используя C++ можно получить все то же + нормальная производительность, но получается, что ряд мелких недочетов этому мешают и для фреймворков выбирается Java. Но имхо — эти недочеты устранимы без VM.

Здравствуйте, enji, Вы писали:

E>Что ты вообще имеешь в виду под усложнением синтаксиса в с++11/14?
Если в терминологии wikipedia{C++11}{C++14}:
lamda-выражения считаю бесполезными — если мне надо вызвать несколько функций, я их вызову без lambda.
Alternative function syntax — зачем?
User-defined literals — бесполезно.
Function return type deduction — ужас
Variable templates — бесполезно

E>она во многих отношениях слабее явы. До нелюбимого тобой с++11 там даже потоков не было... Что касается опций линковки — ты о чем?
Я и говорю, что во многих отношениях слабее явы. Если нужно собрать один и тот-же проект в разных дистрибутивах линукса, то процедуру сборки прийдется усложнять. Это проблема решаемая,
но все же она присутствует и средства сборки линукс не полностью интуитивны для программистов, которые не знают auto-tools или тонкости make. Потом, при линковке того же буста, в разных дистрибутивах часто возникают проблемы с заголовчными файлами.

E>Опять же, более сильная стандартная библиотека не взлетит на тех же мелких контроллерах. Все равно будут какие-то подмножества в каждой области применения.
Правильно — возможно, нужна еще одна, более полная библиотека, аналогичная библиотеке Java.

E>Чтобы расстрелять стек / кучу / etc, достаточно обратиться по мусорному указателю. С учетом отсутствия контроля со стороны рантайма, это сделать элементарно — неинициализированная переменная, дважды вызвали деструктор, вышли за границы массива, ...
Если программа дважды вызывает деструктор или обращается по мусорному указателю, то в ней баг и она работать не будет. Да, на C++ найти этот баг может быть несколько сложнее, но в больших проектах для этого можно использовать собственные менеджеры памяти и тот же valgrind(наверняка в Windows есть аналогичные средства). Да — проблемы с памятью в программах на С++ встречаются, но они решаемы, если программист понимает, что делает. Для этого всего то нужно потратить две недели-месяц на чтение книг по С++.

E>Умные указатели — это не сборщик мусора. Их надо осознанно использовать, обычные указатели никуда не деваются — т.е. есть риск ошибки, циклы разруливаются только руками — снова есть риск ошибки... Сравни это с явовской ссылкой — с ней что-то сделать не так уже значительно сложнее.
Та или иная система учета памяти в С++ была бы полезна. Но для этого не нужен сборщик мусора — система в Objective C достаточно удобна, есть и другие. И медленная VM для этого — перебор.

E>В смысле — в один exe склеены несколько файлов? Хз насчет Alpha, но win/lin в одном файле я что-то пока не видел А вот явовские софтины, запускающиеся и там и там — встречались
Да я тоже не встречал, как впрочем и живых Alpha процессоров. Наверное, достаточно распространять по бинарнику для каждой архитектуры.

E>Мы ж про бизнес-приложения? Тут безопасность рулит, а производительность — не принципиальна. Тут сбоку как раз темка про ява/с++, можешь там ознакомиться
Используя C++ можно получить все то же + нормальная производительность, но получается, что ряд мелких недочетов этому мешают и для фреймворков выбирается Java. Но имхо — эти недочеты устранимы без VM.