dmz>>Кстати, хочу сказать, что я не призываю писать жесткий рилтайм на Java, однако же сомневаюсь, что его dmz>>пишут на C++.
E>Таки пишут. E>За счет того, что если C++ применять как C with classes, то писать на нем гораздо приятнее, чем на C.
Ну а много ли при этом остается от великого и ужасного сложного C++ ? "C с классами" — это, считай, та-же Javа по сложности. Ну там, за вычетом управления памятью.
Это ли имеется ввиду под "сложным инструментом для сложных задач" ?
E>А по поводу серверов -- в принципе согласен. Не зря же Java C++ в секторе server side значительно потеснила.
"Значительно потеснила" это я боюсь, не совсем то выражение. Думаю, правильнее сказать, что в основном, кроме legacy-приложений.
E>Хотя в любой задаче есть свои исключения. И в большей степени качество и пр. параметры определяют не столько E>языки, сколько люди.
E>А поскольку на подготовку нормального C++ программиста требуется гораздо больше времени и сил, то и E>результат получается соответствующий.
Вот-вот, интересно, какой?
Варианты:
1) Пишется качественный и высокопроизводительный софт
2) Значительная часть кода пишется не "нормальными" С++ программистами?
3) Поскольку "нормальных" программистов днем с огнем не найдешь, и time-to-market проекта значительно увеличивается за счет поиска "нормальных", либо растут издержки на зарплаты, либо и то, и другое?
dmz>А что вам — названия компаний и проектов привести? Вам названия проектов что-то скажут? dmz>Jazzer знает, о чем я говорю И что проект A***a в ******** Bank(это он был переписан с Java из соображений производительности?) тёк и дампился долгое время — тоже Посмотрим на его возражения.
не, он изначально писался на плюсах. А вот другой, в котором не меньше важна производительность, был писан сразу дна жабе, и с производетльностью были большие проблемы, причем проблемы как раз типа так CreatorCray описал.
Только еще хуже — там сервер просто корился ( напоминаю, речь идет о жаве ).
Здравствуйте, CreatorCray, Вы писали:
dmz>>В одном известном тебе операторе сотовой связи, CC>В городке N в компании M стоит софт, написанный на С== и который делает дело X. Так вот тот софт по производительности делает вообще всё, что когда либо писали и напишут CC>Настолько неаргументированно можно заявить вообще все что угодно.
dmz>>... очень хорошо известную тебе систему. CC>Туды же... в качель, ага... CC>Более того, приводя пример не мешало бы несколько конкретизировать и приводить хотя бы проверяемые данные. Потому как так можно написать все что угодно.
Все нормально. dmz писал ссылался на то, что известно именно мне (см. выделенное)
Подтверждаю — он говорит правду, именно мне это известно, все правда.
Остальное — коммерческая тайна соответствующих (известных нам с dmz ) компаний.
Здравствуйте, dmz, Вы писали:
E>>Таки пишут. E>>За счет того, что если C++ применять как C with classes, то писать на нем гораздо приятнее, чем на C.
dmz>Ну а много ли при этом остается от великого и ужасного сложного C++ ? "C с классами" — это, считай, та-же Javа по сложности. Ну там, за вычетом управления памятью.
Как раз управления памятью в жестком real-time нет (по крайней мере по моему опыту). Память выделяется заранее и затем переиспользуется. Чтобы никакой new/delete в неподходящий момент не вмешался в работу.
А помогают как раз классы с деструкторами, вызывающимися в определенный и конкретный момент (RAII). Аргументы ссылки вместо указателей. Если есть возможность пользоваться шаблонами, то шаблоны позволяют упрощать код и не использовать макросы (хотя далеко не для всех экзотических real-time платформ есть шаблоны ).
dmz>Это ли имеется ввиду под "сложным инструментом для сложных задач" ?
Иногда работа с темпом даже в 100 миллисекунд бывает очень сложной задачей.
dmz>Вот-вот, интересно, какой?
Если в команде оказывается хотя бы один не очень опытный C++ разработчик, то плачевный.
dmz>Варианты:
dmz>1) Пишется качественный и высокопроизводительный софт dmz>2) Значительная часть кода пишется не "нормальными" С++ программистами? dmz>3) Поскольку "нормальных" программистов днем с огнем не найдешь, и time-to-market проекта значительно увеличивается за счет поиска "нормальных", либо растут издержки на зарплаты, либо и то, и другое?
Провокационные варианты
Естественно, что мной и моей командой пишется только качественный и высокпроизводительный софт. Я в этом даже не сомневаюсь
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
dmz>>Если бы решение было действительно взвешенным, то сначала бы на С++ переписали критические места, dmz>>и это при том, что не удалось их оптимизировать без переписывания. HotSpot у Java работает вполне неплохо. J>я деталей не знаю, правда. Просто факт.
Угу. Но решение "переписать все" — оно не свидетельствует о взвешенном и разумном подходе.
У Java есть JNI, критичные вещи можно было бы вынести туда. Хотя может быть исходный пример был
настолько крив, что ему помогло не столько переписывание на "С++", сколько переписывание вообще.
Зная местную специфику, согласись, это может быть правдой.
J>Ну и плюс в соседнем большом "фирмообразующем" проекте, о котором ты знаешь, ядро на плюсах, а гуй на жаве.
Ну да, про стабильность серверной части мы наслышаны Надеюсь, все стало хорошо — но заняло это не один год в итоге.
dmz>>И плоды видимо переписывания с джавы, когда внутри метода сервера выделяется память, присваивается dmz>>указателю, разыменовывается и возвращается ссылка — я тоже видел., J>ну это вообще был код больных людей
На Java был бы валидный код — о памяти позаботился бы GC
J>Более того, я знаю фирмы, которые гоняют трафик, в чем-то сравнимый с сотовым — там все на С++ (преимущественно J>библиотека АСЕ плюс всякие бусты и прочая) — все летает и отлично масштабируется.
Да не вопрос, что можно! Вопрос только, сколько это стоит и нужно ли это на самом деле.
J>на то, что оно во сколько-то раз (точно не знаю) медленнее, чем древняя и морально устаревшая сиплюсовая версия — J>об этом даже никто и не задумывается пока.
Здравствуйте, remark, Вы писали:
R>Ну а как насчёт, ну не знаю, доступа к регистрам аппаратуры, или "написания программы на машинном коде" (ну это когда ты пишешь программу на яву, но при этом фактически знаешь, что будет делать процессор).
Попробуй записать на C++ что-нибудь в порт под виндой, а я посмотрю
R>Пусть для чего-то мне понадобится в начале сделать свою библиотеку, и синтаксис будет не такой красивый. Но преград нет. В этом суть.
Преграда есть. Это ограниченность наших способностей. Чем сложнее иструмент, тем менее сложные задачи мы можем решать, т.к. часть наших усилий тратится на преодоление сложности иструмента. Столь же мощный, но более простой иструмент напротив позволяет высвобождать наш потенциал и направлять его на решение самой задачи.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Шахтер, Вы писали:
Ш>>Усилий на проверку корректности поведения компилятора надо потратиь значительно больше, чем на его разработку.
J>Ну так на это тест-сьюты есть.
Ага. Они самые. А ты прикинь, сколько усилий надо приложить, чтобы напридумывать разных головоломных ситуаций и понять, как они должны по стандарту обрабатываться. И это в C++ !
Поэтому они и стоят бешенных денег.
Здравствуйте, eao197, Вы писали:
E>За счет того, что если C++ применять как C with classes, то писать на нем гораздо приятнее, чем на C.
Да и существенная доля С++ проектов которые таки отличаются стабильностью и производительностью именно на С с классами + чуть чуть темплейтов пишутся. Остальные навороты в зоопарке зачастую не нужны.
Выскажу одно свое подозрение: чтоб прогер качественно писал на С++ ИМХО нужно чтобы он представлял как это все работает. В смысле: после компиляции.
Здравствуйте, dmz, Вы писали:
CC>>На любом языке можно писать плохо. Любую архитектуру можно спланировать наикривейшим способом. Язык то тут при чем? dmz>Мое утверждение: C++ не нужен для разработки серверов в 99.9% случаев.
Ну, сервера серверам рознь. Есть сервера приложений, сервера баз а есть и сервера для обработки данных, которые на них поступают.
dmz>тащить в ядра ОС или во встроенные устройства STL с boost пока решаются, видимо, только очень отдельные оригиналы.
И слава те Господи! Если на STL еще не особо претензий накопилось то буст просто полный атас.
dmz>Как вы собираетесь их проверять? Вам выдать исходники упомянутых проектов для самостоятельной сборки и проверки, что ли?
Ну, тута я децл погорячился. Просто частое употребление фраз типа "в одном известном мне" создает впечатление придуманности, что ли.
dmz>Очень красиво звучит — When High Performance Does Matter. dmz>На деле — 90% — маргетинговый буллщит, реальный опыт внедрения в одном из ведущих российских операторов сотовой связи — превышение сроков, бюджетов, огромная головная боль при разработке, долгий период нестабильности, дорогая поддержка
А было бы все иначе (в лучшую сторону разумеется) если он был бы написан теми же людьми с той же архитектурой но на Java? Имхо не настолько там в языке дело. Просто на Java плохой код не приводит к таким последствиям как на С++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Шахтер, Вы писали:
E>>>К сожалению, если сравнивать, например, с компилятором D, то являются жутко медленными. Се ля ви.
Ш>>Языки разные. Кроме того, если ты не используешь "навороченные" библиотеки с матерноэтажными шаблонами типа boost, то скорость компиляции очень хорошая.
E>Достаточно начать использовать хотя бы часть из STL (std::string, std::list, std::vector или std::set/map), то скорость компиляции уже заметно падает. А без STL я лично уже не хочу программировать на C++.
Тут вопрос не в STL даже, и не в шаблонах, а в пресловутой модели включения.
Представь, что у тебя 100 исходных файлов, каждый из которых включает некий заголовок MyCoolVector.h. И в каждом исходнике ты используешь MyCoolVector<int>. Как результат, при сборке проекта ты будешь этот класс инстантинировать 100 раз вместе с его методами, т.е. компилятор выполнит одну и ту же работу 100 раз, а потом ещё и линкеру придется разгребать эту кучу и выкидывать лишнее. Отсюда и скорость сборки.
Такая модель сложилась исторически.
Необходимо от неё отходить, для чего и в языке, и в его реализациях нужны определённые изменения.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Gajdalager, Вы писали:
G>>Как можно на плюсах писать программы, которые лучше "тянут" по портируемости чем Жава/дотНет??? CC>Это .NET портируемый? Ну портируйте кто нить что нить написанное хотяб под .NET 2.0 на линух. CC>Тогда как С++ проектов с никсов под вынь перетянуто множество.
В теории .Нет кроссплатформенный, а моноплатформенность .Нета происходит не от каких-либо просчетов в архитектуре или спецификации, а из-за политики МС.
Кроме того, при написании програм на Жаве(и, в теории, на .Нете), кроссплатформенность получаем сразу и без усилий.. Чтобы написать непортируемую программу, нужно постараться... С другой стороны, чтобы сохранить на плюсах портируемость на уровне исходников(не говоря уже про портируемость исполняемого кода), нужно постоянно учитывать это на этапе написания кода.
dmz>>Мое утверждение: C++ не нужен для разработки серверов в 99.9% случаев. CC>Ну, сервера серверам рознь. Есть сервера приложений, сервера баз а есть и сервера для обработки данных, которые CC>на них поступают.
При этом отличие серверов БД от прочих в том, что они:
1) Зачастую полностью определяют производительность систем, которые их используют
2) Сравнительно плохо кластеризуются
Из этого определенным образом следует, что при разработке серверов БД нам нужна вся
производительность до капли — это критично.
Но тут, внимание, вопрос — а на С++ ли они пишутся? Не на C ли, случаем?
dmz>>Как вы собираетесь их проверять? Вам выдать исходники упомянутых проектов для самостоятельной сборки и проверки, что ли?
CC>Ну, тута я децл погорячился. Просто частое употребление фраз типа "в одном известном мне" создает впечатление CC>придуманности, что ли.
Хоть я работаю в не в упомянутом банке и не в упомянутом-же сотовом операторе, не думаю, что упоминать их, особенно после рассказа о некоторых внутренних особенностях — этично.
Да и будет ли вам легче, если будете знать, очередной раз активируя скретч-карту или засовывая деньги в аппарат экспресс-оплаты, что ваши деньги поступают на счет почти исключительно молитвами тех. саппорта ?
CC>А было бы все иначе (в лучшую сторону разумеется) если он был бы написан теми же людьми с той же архитектурой но CC>на Java? Имхо не настолько там в языке дело. Просто на Java плохой код не приводит к таким последствиям как на CC>С++.
Думаю, было бы лучше. Главным образом потому, что существуют аналоги этого поделия, реализованные на J2EE и они работают вполне нормально. Аналог же этого я видел один, и он был так же крив, и проблемы с ним были очень похожие.
Здравствуйте, dmz, Вы писали:
dmz>Угу. Но решение "переписать все" — оно не свидетельствует о взвешенном и разумном подходе. dmz>У Java есть JNI, критичные вещи можно было бы вынести туда.
не все, а серверная часть (т.е. та, которая считает математику, и сам транспорт).
Остальное осталось на жабе.
dmz>Хотя может быть исходный пример был dmz>настолько крив, что ему помогло не столько переписывание на "С++", сколько переписывание вообще. dmz>Зная местную специфику, согласись, это может быть правдой.
Соглашусь, просто на всякий случай замечу, что это не зависит от языка
dmz>На Java был бы валидный код — о памяти позаботился бы GC
Вот как раз с GC и была проблема.
Он банально не успевал чистить память, в результате все корилось из-за нехватки памяти.
Явный вызов gc тоже не был вариантом из-за неизвестного времени работы (сам знаешь, что такое софт, занимающийся скоростной торговлей на бирже, и какова стоимость малейшей задержки в трансорте).
В этом смысле С++ на голову выше управляемых языков, именно тем, что, благодаря наличию в языке деструкторов, всегда точно известно, сколько у тебя чего, когда что освободилось, и т.п.
Причем даже если ты будешь использовать всякие системы со счетчиками ссылок типа boost::shared_ptr, когда неизвестно точно, в какой момент что умрет, известно, сколько времени может занять смерть (вызов деструктора) плюс известны возможные места смерти (т.е. места, где декрементится счетчик).
А в жабе он вызовется хз когда и будет работать хз сколько вреени, ты же не можешь ему сказать, что, мол, освободи мне мегабайт, чтоб можно было дальше работать, и уйди нафиг в тень...
J>>Более того, я знаю фирмы, которые гоняют трафик, в чем-то сравнимый с сотовым — там все на С++ (преимущественно J>библиотека АСЕ плюс всякие бусты и прочая) — все летает и отлично масштабируется.
dmz>Да не вопрос, что можно! Вопрос только, сколько это стоит и нужно ли это на самом деле.
Насколько я знаю, немного. Там сидят, по-моему, всего три реально высококвалифицированных программера на С++, и им этого вполне достаточно, проект развивается и приносит нехилые бабки.
J>>на то, что оно во сколько-то раз (точно не знаю) медленнее, чем древняя и морально устаревшая сиплюсовая версия — J>об этом даже никто и не задумывается пока.
dmz>Бывает
Вот о чем и речь. Что в 80% случаев не в языке дело.
Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>Ну-ну, вон три человека сумели компилятор С++ с экспортом шаблонов написать, да еще и на С. Наверное, справились бы и с немерле.
Нет, с Немерле не справились бы. Как бы они вывод типов написали бы? А вот компилятор C++ на Немерле написать — проще некуда. Только всё равно на 100% поддержку C++ сделать нельзя, как говорится, by design.
Здравствуйте, Шахтер, Вы писали:
Ш>С++, кстати, замечательно подходит для написания компиляторов, учитывая, что хороший компилятор содержит массу алгоритмически нетривиальных вещей.
Нет, как раз на ФЯ вроде Nemerle псать компиляторы проще. Вообще, алгоритмически нетривиальные вещи на C++ неудобно решать. А вот в ML-языках имеются алгебраические типы и паттерн матчинг, что позволяет банально меньше писать. И это, заметьте, влияет не только (и не столько) на скорость написания, но и на читабельность кода.
Здравствуйте, Шахтер, Вы писали:
E>>Достаточно начать использовать хотя бы часть из STL (std::string, std::list, std::vector или std::set/map), то скорость компиляции уже заметно падает. А без STL я лично уже не хочу программировать на C++.
Ш>Тут вопрос не в STL даже, и не в шаблонах, а в пресловутой модели включения.
+1
Ш>Представь, что у тебя 100 исходных файлов, каждый из которых включает некий заголовок MyCoolVector.h. И в каждом исходнике ты используешь MyCoolVector<int>.
Да ладно бы дело было в MyCoolVector. А то ведь просто напишешь в cpp-файле #include <string> и все -- время компиляции увеличилось на порядок
Ш>Такая модель сложилась исторически. Ш>Необходимо от неё отходить, для чего и в языке, и в его реализациях нужны определённые изменения.
Идеи есть какие-нибудь?
А то у меня они слишком радикальные -- использовать Scala и D вместо C++.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, konsoletyper, Вы писали:
K>Вообще, алгоритмически нетривиальные вещи на C++ неудобно решать.
Пример можно?
Именно алгоритмической нетривиальности (а то приводящиеся обычно в качестве демонстрации pattern matching-а разборы синтаксичеких конструций такими назвать довольно сложно).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, Lorenzo_LAMAS, Вы писали:
L_L>>Ну-ну, вон три человека сумели компилятор С++ с экспортом шаблонов написать, да еще и на С. Наверное, справились бы и с немерле.
K>Нет, с Немерле не справились бы. Как бы они вывод типов написали бы?
Интересно как вывод типов в продукте может зависеть от языка реализации этого продукта? По твоему трансляторы пролога тоже невозможно на C/C++ написать?
K>А вот компилятор C++ на Немерле написать — проще некуда. Только всё равно на 100% поддержку C++ сделать нельзя, как говорится, by design.
И что проект A***a в ******** Bank(это он был переписан с Java из соображений производительности?) тёк и дампился долгое время — тоже 
).
Если нам не помогут, то мы тоже никого не пощадим.
