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

VD>Сразу оговорюсь... аноним — это не я.

Я и не сомневался.

VD>Я думаю, самая большая проблема этого продуката — С++.

...Э ... у... ну... так уж получилось. Исторически. И не факт, что если бы в 2001-2002 годах SObjectizer был бы реализован на чем-нибудь управляемом (ближе всего в это время была Java), то SObjectizer получился бы настолько быстрым, каким он является сейчас.

VD>Все же не серьзно рассчитвать, что на серевере будет жить море кода с ручным управлением памяти написанного на небезопасном языки и при этом не будет моря глюков.

Мне кажется, что существующее положение вещей данный довод опровергает. Существует масса кода на C/C++, которые работают в режиме 24x7, не глючат и не падают. Существует не мало кода на Java, который должен был бы работать в режиме 24x7, но падает.

Разговоры о том, что на C++ нельзя писать надежные программы -- это от лукавого. Очень похожи на разговоры о том, что на динамических языках нельзя писать надежные программы. И то и другое не верно. Скорее C++ не облегчает написание надежных программ. Поэтому первый же дятел-разработчик легко вызывает крах большой системы.

К особенностям C++ SObjectizer добавляет еще и свои прибабахи, к которым нужно привыкнуть. Но после этого использовать SObjectizer не сложно.

Меня же больше напрягает в C++ отсутствие настолько продвинутых фреймворков, как JDK или .NET. Поэтому даже выбор библиотеки для работы с HTTP-транспортом или с РСУБД выливается в совершенно не нужную головную боль. И затем оказывается, что в реальной системе от SObjectizer-а всего 20% кода, а все остальное -- это работа с какими-нибудь libcurl, libiconv, otl, libxml2 и пр.