Соседний топик "java vs. c++" навевает вопрос причин отсутствия фреймворков для разработки корпоративных приложений(вроде Spring, Struts) и серверов приложений на C++.
Представляются возможными такие причины:
1) В Java по-умолчанию предоставляются стандартные переносимые функции вроде управления потоками.
Все эти функции доступны без дополнительной настройки и линковки, что полезно для больших проектов,
в которых не удобно для каждого развертывания линковать 5-10 библиотек вроде pthread, boost и пр.
2) У JVM есть преимущество безопасности при исполнении кода, т.к. VM контролирует доступ при каждом обращении
приложения к памяти. По-моему, это единственное существенное преимущество JVM перед компилируемым кодом. Впрочем, безопасность выполнения кода можно обеспечить на C++ средствами ОС (виртуальная память, процессы).
3) Java лучше интегрирован с браузерами.
При различиях в производительности приложений на C++ и Java удивляет, что на C++ до сих пор нет заметных
фреймворков.

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

lpd>Соседний топик "java vs. c++" навевает вопрос причин отсутствия фреймворков(вроде Spring, Struts) и
lpd>серверов приложений на C++.

Во что я ввязываюсь...

Основным посылом прошлого топика было:
— отсутствие универсальной, распределенной, переносимой и т.д. системы сборки (являющейся стандартом де факто и работающей под все платформы и проекты). Причины отсутствия очевидны.
— отсутствие признанных стандартом библиотек (хотя нынче boost и qt претендуют на это) покрывающих большинство потребностей. Там где у Java одна-две приличных и распространенных библиотеки, у C++ десяток вариантов, не все из которых можно назвать законченным решением. И каждый пользуется, к чему душа ближе.
— Java библиотеки проще в эксплуатации, положил куда надо и все работает. Для C++ у каждой свой подход, что-то требует cmake, что-то собирается через autotools/nmake, где-то своя система сборки. Где то мега скрипт не работоспособный без установленных perl, python & ruby. В итоге, что бы включить библиотеку в проект надо обязательно почитать README/INSTALL и понять что с ней делать. Для кроссплатформенных решений легко могут выплыть разные средства сборки и куча подводных камней. Плюс каждая OS & Arch — требует собственный билд (а зачастую просто копию библиотеки).
— Стандартная библиотечка Java побогаче.
В итоге C++ тупо менее удобен Java когда мы говорим о внешних зависимостях и извращениях со сборкой. И тупо быстрей когда у нас одна математика (и если руки не из жопы).

lpd>Представляются возможными такие причины:
lpd>1) В Java по-умолчанию предоставляются стандартные переносимые функции вроде управления потоками.
lpd>Все эти функции доступны без дополнительной настройки и линковки, что полезно для больших проектов,
lpd>в которых не удобно для каждого развертывания линковать 5-10 библиотек вроде pthread, boost и пр.
выше.
lpd>2) У JVM есть преимущество безопасности при исполнении кода, т.к. VM контролирует доступ при каждом обращении
lpd>приложения к памяти. По-моему, это единственное существенное преимущество JVM перед компилируемым кодом. Впрочем, безопасность выполнения кода можно обеспечить на C++ средствами ОС (виртуальная память, процессы).
Память это всего лишь один из ресурсов, помимо нее есть соединения сетевые с СУБД, файловые дескрипторы и прочие радости. И там особой разницы между C++ и Java нет. Плюс умные указатели.
lpd>3) Java лучше интегрирован с браузерами.
Это вы мало пользовали Java в браузерах. Когда все эти "write once run everywhere" приложения тупо не работают с новыми JRE или требуют строго 32 JRE или старого браузера и т.д.
Нынче лучше всех интегрирован JavaScript.
lpd>При различиях в производительности приложений на C++ и Java удивляет, что на C++ до сих пор нет заметных
lpd>фреймворков.

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

lpd>1) В Java по-умолчанию предоставляются стандартные переносимые функции вроде управления потоками.

Начиная с C++11 управление потоками входит с стандарт.

lpd>Все эти функции доступны без дополнительной настройки и линковки, что полезно для больших проектов,
lpd>в которых не удобно для каждого развертывания линковать 5-10 библиотек вроде pthread, boost и пр.

А зачем для каждого развёртывания повторять (видимо вручную) какие-то операции? Напиши скрипт и дело в шляпе.

lpd>2) У JVM есть преимущество безопасности при исполнении кода, т.к. VM контролирует доступ при каждом обращении
lpd>приложения к памяти. По-моему, это единственное существенное преимущество JVM перед компилируемым кодом. Впрочем, безопасность выполнения кода можно обеспечить на C++ средствами ОС (виртуальная память, процессы).

Плюс средствами компилятора. Плюс возможностью компиляции в управляемую среду.

lpd>3) Java лучше интегрирован с браузерами.

О чём конкретно речь? Для C++ есть Emscripten, с помощью него например за четыре дня спортировали Unreal Engine в JavaScript:
http://www.youtube.com/watch?v=BV32Cs_CMqo

lpd>При различиях в производительности приложений на C++ и Java удивляет, что на C++ до сих пор нет заметных
lpd>фреймворков.

Для какой-то конкретной области или вообще?

lpd>Представляются возможными такие причины:

Перечисленные тобой причины практически ортогональны наличию/отсутствию фреймворков.

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

lpd>>Все эти функции доступны без дополнительной настройки и линковки, что полезно для больших проектов,
lpd>>в которых не удобно для каждого развертывания линковать 5-10 библиотек вроде pthread, boost и пр.

EP>А зачем для каждого развёртывания повторять (видимо вручную) какие-то операции? Напиши скрипт и дело в шляпе.
Может потребоваться редактирование скрипта/настроек в зависимости от ОС у программиста если нужны несколько отдельно уставнавлиеваемых/компилируемых библиотек.

lpd>>2) У JVM есть преимущество безопасности при исполнении кода, т.к. VM контролирует доступ при каждом обращении
lpd>>приложения к памяти. По-моему, это единственное существенное преимущество JVM перед компилируемым кодом. Впрочем, безопасность выполнения кода можно обеспечить на C++ средствами ОС (виртуальная память, процессы).

EP>Плюс средствами компилятора. Плюс возможностью компиляции в управляемую среду.
Без reflection в большинстве случаев можно обойтись. Мне на C++ никогда reflection не были нужны.

EP>Для какой-то конкретной области или вообще?
Имею ввиду отсутствие фреймворков для бизнес-приложений вроде Spring/Struts и множества других на Java.

Вот и в моих рассуждениях получается, что единственным препятствием для использования C++ в бизнес-фреймворках является
разбросанность базовых функций по множеству библиотек и следующее из этого некоторое неудобство сборки. Выходит, что
C++ для вытеснения Java и C# из области бизнес-приложений по-существу не хватает только реализации стандартной библиотеки Java.

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

lpd>>>Все эти функции доступны без дополнительной настройки и линковки, что полезно для больших проектов,
lpd>>>в которых не удобно для каждого развертывания линковать 5-10 библиотек вроде pthread, boost и пр.
EP>>А зачем для каждого развёртывания повторять (видимо вручную) какие-то операции? Напиши скрипт и дело в шляпе.
lpd>Может потребоваться редактирование скрипта/настроек в зависимости от ОС у программиста если нужны несколько отдельно уставнавлиеваемых/компилируемых библиотек.

Да, тут согласен — сторонние библиотеки для разных OS могут требовать разных процедур. Думал речь про развертывание в одинаковых средах.

lpd>>>2) У JVM есть преимущество безопасности при исполнении кода, т.к. VM контролирует доступ при каждом обращении
lpd>>>приложения к памяти. По-моему, это единственное существенное преимущество JVM перед компилируемым кодом. Впрочем, безопасность выполнения кода можно обеспечить на C++ средствами ОС (виртуальная память, процессы).
EP>>Плюс средствами компилятора. Плюс возможностью компиляции в управляемую среду.
lpd>Без reflection в большинстве случаев можно обойтись. Мне на C++ никогда reflection не были нужны.

Не понял причём тут reflection, речь же шла про безопасный доступ к памяти.

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

lpd>Вот и в моих рассуждениях получается, что единственным препятствием для использования C++ в бизнес-фреймворках является
lpd>разбросанность базовых функций по множеству библиотек и следующее из этого некоторое неудобство сборки. Выходит, что
lpd>C++ для вытеснения Java и C# из области бизнес-приложений по-существу не хватает только реализации стандартной библиотеки Java.

И каких же базовых функций не хватает в связке C++11, Boost, Qt?
Да неудобство есть, но при выборе языка на него кто вообще посмотрит? Потратить C времени на библиотеку для крупного проекта не сложно. Для кучи мелких можно таскать с собой пару заголовочных файлов и пользоваться общей кучей собранных библиотек. Это неудобство, а не проблема.

Это три разных языка. Костяк у них конечно общий, но возможности, удобство и особенности довольно разные.
И да, если бы для их вытеснения было бы достаточно стандартной библиотеки, то появилось бы библиотека, а не новые языки.

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

EP>Здравствуйте, lpd, Вы писали:
lpd>>>>2) У JVM есть преимущество безопасности при исполнении кода, т.к. VM контролирует доступ при каждом обращении
lpd>>>>приложения к памяти. По-моему, это единственное существенное преимущество JVM перед компилируемым кодом. Впрочем, безопасность выполнения кода можно обеспечить на C++ средствами ОС (виртуальная память, процессы).
EP>>>Плюс средствами компилятора. Плюс возможностью компиляции в управляемую среду.
lpd>>Без reflection в большинстве случаев можно обойтись. Мне на C++ никогда reflection не были нужны.

EP>Не понял причём тут reflection, речь же шла про безопасный доступ к памяти.
Да, насчет средств компилятора согласен, но их на данный момент никаких нет, что выглядит недостатком.

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

1>И каких же базовых функций не хватает в связке C++11, Boost, Qt?
Boost еще надо прилинковать — но он не очень и нужен допустим. Qt предлагает средства для UI и работы с
Bluetooth, NFC и т.п., но эти средства скорее лишние для framework, зато вроде бы отсутствует HTTP. Не уверен, что в QT
достаточные для web-приложений модули для работы с Web.

1>Это три разных языка. Костяк у них конечно общий, но возможности, удобство и особенности довольно разные.
1>И да, если бы для их вытеснения было бы достаточно стандартной библиотеки, то появилось бы библиотека, а не новые языки.
Если бы C++ развивался не в сторону по большей части не нужных и несколько усложненных C++11 и C++14, а появился бы переносимый и мощный stl, то C++ заменил бы Java и C#. stl в C++ в том виде, в котором он сейчас, нужен для сравнительно быстрого портирования базовых программ между разными linux и в embedded, но он недостаточно прост и силен для использования в бизнес-приложениях.
Но, возможно, это не единственная причина, поэтому я и поднял исходный вопрос.

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

lpd>Если бы C++ развивался не в сторону по большей части не нужных и несколько усложненных C++11 и C++14,
вот не надо. auto, замыкания, for — все это нужно и не усложнено. rvalue — усложнено, но местами сильно упрощает и увеличивает производительность

lpd> а появился бы переносимый и мощный stl, то C++ заменил бы Java и C#.
переносимый и мощный stl сразу убирает плюсы из всяких там embedded. Собственно и в яве разные библиотеки для каких-нить мобил или карт и для веба...

lpd> stl в C++ в том виде, в котором он сейчас, нужен для сравнительно быстрого портирования базовых программ между разными linux и в embedded, но он недостаточно прост и силен для использования в бизнес-приложениях.
lpd>Но, возможно, это не единственная причина, поэтому я и поднял исходный вопрос.

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

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

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

lpd>>Если бы C++ развивался не в сторону по большей части не нужных и несколько усложненных C++11 и C++14,
E>вот не надо. auto, замыкания, for — все это нужно и не усложнено. rvalue — усложнено, но местами сильно упрощает и увеличивает производительность
auto да, удобен. Как и умные указатели. Но 10 видов одного и того же по смыслу for не нужны.

lpd>> а появился бы переносимый и мощный stl, то C++ заменил бы Java и C#.
E>переносимый и мощный stl сразу убирает плюсы из всяких там embedded. Собственно и в яве разные библиотеки для каких-нить мобил или карт и для веба...
О том и речь, что для конкуренции с Java нужна еще одна стандартная библиотека. Более мощная, переносимая и простая в сборке.

E>для бизнес-приложений есть более безопасные языки вроде шарпа/явы. Врядли плюсы могут их подвинуть
Собственно единственным большим плюсом Java и C#, помимо библиотек, видится сходство с C++. У Java и C# донельзя тормозная VM, а сборка мусора реализуется при необходимости в C++, тем более что есть valgrind. Переносимость, которая при появлении java считалась основным преимуществом VM нужна только для малоиспользуемых java-апплетов, т.к. на C++ вообщем то тоже можно распространять код для разных платформ в одном исполняемом файле.

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

lpd>Имею ввиду отсутствие фреймворков для бизнес-приложений вроде Spring/Struts и множества других на Java.

С++ в силу некоторых причин не подходит для написания бизнес-приложений. Поэтому соответствующих фреймворков в нём и не наблюдается. Это настолько явная и ясная причина, что меня удивляет вообще наличие подобных вопросов.

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

lpd>auto да, удобен. Как и умные указатели. Но 10 видов одного и того же по смыслу for не нужны.

не 10, а два — for (x = 0; x < 10; ++x) и for(x : list). И смысл у них как-бы разный... Или ты под for еще и while подразумеваешь?

lpd>О том и речь, что для конкуренции с Java нужна еще одна стандартная библиотека. Более мощная, переносимая и простая в сборке.

Стандартная библиотеке в сборке просто таки элементарна — ее вообще обычно собирать не надо Переносимость обычно противоречит мощности — скажем на авр-ках нет потоков / файловой системы, а плюсы там чувствуют себя прекрасно

lpd>Собственно единственным большим плюсом Java и C#, помимо библиотек, видится сходство с C++.
Большой плюс явы и шарпа — управляемая среда исполнения, которая дает по рукам перед тем, как программа расстреляет стек скажем. А на си ничто не мешает его расстрелять и получить донельзя странную ошибку в произвольный момент времени

lpd>У Java и C# донельзя тормозная VM, а сборка мусора реализуется при необходимости в C++, тем более что есть valgrind.

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

lpd>на C++ вообщем то тоже можно распространять код для разных платформ в одном исполняемом файле.

Да ладно. Начнем с разных форматов файлов и закончим разным АПИ на разных платформах...

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

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

lpd>>auto да, удобен. Как и умные указатели. Но 10 видов одного и того же по смыслу for не нужны.

E>не 10, а два — for (x = 0; x < 10; ++x) и for(x : list). И смысл у них как-бы разный... Или ты под for еще и while подразумеваешь?
Я считаю, что язык программирования должен быть простой как C++(или Java). С++11 и С++14 требуют изучения 10ков дополнительных вариантов синтаксиса для по-большей части редко нужных вещей. Т.е. усложнение языка во многих случаях не оправдано пользой.

E>Стандартная библиотеке в сборке просто таки элементарна — ее вообще обычно собирать не надо Переносимость обычно противоречит мощности — скажем на авр-ках нет потоков / файловой системы, а плюсы там чувствуют себя прекрасно
Стандартная библиотека в некоторых отношениях слабее библиотеки Java, при этом сложнее. Из-за чего часто получается, что в проекте используется много небольших библиотек, каждая из которых требует своих опций линковки на каждом из вариантов Linux.

lpd>>Собственно единственным большим плюсом Java и C#, помимо библиотек, видится сходство с C++.
E>Большой плюс явы и шарпа — управляемая среда исполнения, которая дает по рукам перед тем, как программа расстреляет стек скажем. А на си ничто не мешает его расстрелять и получить донельзя странную ошибку в произвольный момент времени
Контроль стека имеет теоретическую ценность: в реальности чтобы расстрелять стек нужны или бесконечная рекурсия, или неподходящий алгоритм, что выявить не столь сложно.

lpd>>У Java и C# донельзя тормозная VM, а сборка мусора реализуется при необходимости в C++, тем более что есть valgrind.

E>Она то может быть и реализуется, но как? boehm (или как-то так, не помню названия) — куча ограничений и тормоза вероятно еще почище явовских, смарт-поинтеры — довольно много ручной работы, не защищают от некоторых ошибок. valgrind есть только под линем...
Сборщик мусора при желании можно реализовать перегрузкой new/delete и умными указателями. Да, возможно, синтаксис будет несколько сложнее. Но сборка мусора недостаточная причина для использования VM. В том же objective c учет памяти опциональный.

lpd>>на C++ вообщем то тоже можно распространять код для разных платформ в одном исполняемом файле.

E>Да ладно. Начнем с разных форматов файлов и закончим разным АПИ на разных платформах...
Имею ввиду полностью разный исполняемый код для разных платформ в одном бинарном файле. Код может получаться из одного исходника C++, но с макросами для каждой ОС. Вроде как минимум PE-файлы Windows поддерживали вариант одного бинарника и для x86, и для Alpha.

Если я правильно помню, при появлении Java основным достоинством декларировалась портабельность Java-апплетов, что неактуально. Других существенных достоинств Java, оправдывающих в 8 раз меньшую производительность, кроме теоретически полезной безопасности, обеспечиваемой JVM, по-моему нет.

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

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

lpd>>Имею ввиду отсутствие фреймворков для бизнес-приложений вроде Spring/Struts и множества других на Java.

AD>С++ в силу некоторых причин не подходит для написания бизнес-приложений. Поэтому соответствующих фреймворков в нём и не наблюдается. Это настолько явная и ясная причина, что меня удивляет вообще наличие подобных вопросов.

Ну вот я и пытаюсь выяснить, что это, в действительности, за причины. Но список причин получается короткий и сомнительный.

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

lpd>Я считаю, что язык программирования должен быть простой как C++(или Java). С++11 и С++14 требуют изучения 10ков дополнительных вариантов синтаксиса для по-большей части редко нужных вещей. Т.е. усложнение языка во многих случаях не оправдано пользой.

Ну ты и сравнил. С++ отнюдь не простой, особенно по сравнению с явой. Что ты вообще имеешь в виду под усложнением синтаксиса в с++11/14?

lpd>Стандартная библиотека в некоторых отношениях слабее библиотеки Java, при этом сложнее. Из-за чего часто получается, что в проекте используется много небольших библиотек, каждая из которых требует своих опций линковки на каждом из вариантов Linux.

она во многих отношениях слабее явы. До нелюбимого тобой с++11 там даже потоков не было... Что касается опций линковки — ты о чем?

Опять же, более сильная стандартная библиотека не взлетит на тех же мелких контроллерах. Все равно будут какие-то подмножества в каждой области применения.

lpd>Контроль стека имеет теоретическую ценность: в реальности чтобы расстрелять стек нужны или бесконечная рекурсия, или неподходящий алгоритм, что выявить не столь сложно.

Чтобы расстрелять стек / кучу / etc, достаточно обратиться по мусорному указателю. С учетом отсутствия контроля со стороны рантайма, это сделать элементарно — неинициализированная переменная, дважды вызвали деструктор, вышли за границы массива, ...

lpd>Сборщик мусора при желании можно реализовать перегрузкой new/delete и умными указателями. Да, возможно, синтаксис будет несколько сложнее. Но сборка мусора недостаточная причина для использования VM. В том же objective c учет памяти опциональный.

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

lpd>Имею ввиду полностью разный исполняемый код для разных платформ в одном бинарном файле. Код может получаться из одного исходника C++, но с макросами для каждой ОС. Вроде как минимум PE-файлы Windows поддерживали вариант одного бинарника и для x86, и для Alpha.

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

lpd>Если я правильно помню, при появлении Java основным достоинством декларировалась портабельность Java-апплетов, что неактуально. Других существенных достоинств Java, оправдывающих в 8 раз меньшую производительность, кроме теоретически полезной безопасности, обеспечиваемой JVM, по-моему нет.

Мы ж про бизнес-приложения? Тут безопасность рулит, а производительность — не принципиальна. Тут сбоку как раз темка про ява/с++, можешь там ознакомиться

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

AD>>С++ в силу некоторых причин не подходит для написания бизнес-приложений. Поэтому соответствующих фреймворков в нём и не наблюдается. Это настолько явная и ясная причина, что меня удивляет вообще наличие подобных вопросов.
lpd>Ну вот я и пытаюсь выяснить, что это, в действительности, за причины. Но список причин получается короткий и сомнительный.

Причина собственно одна и она общеизвестна: для решения задач одинаковой сложности C++ и Java/C# требуют от программиста разного уровня подготовки. Что принципиально для бизнеса — не IT компаниям гораздо выгоднее использовать низкоуровневых и хорошо взаимозаменяемых программистов. Так вот как раз Java и C# позволяют это делать безопасно. А C++ в подобном режиме использования обычно приводит к жутким последствиям.

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

Здравствуйте, 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.

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

lpd>Соседний топик "java vs. c++" навевает вопрос причин отсутствия фреймворков(вроде Spring, Struts) и
lpd>серверов приложений на C++.

Qt vs Spring

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

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

Учитывая, что большинство корпоративных приложений проводят время, ожидая ответа от СУБД/сети, то никакого выигрыша от перехода на С++ не получишь.