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

E>>К сожалению, если сравнивать, например, с компилятором D, то являются жутко медленными. Се ля ви.

Ш>Языки разные. Кроме того, если ты не используешь "навороченные" библиотеки с матерноэтажными шаблонами типа boost, то скорость компиляции очень хорошая.

Достаточно начать использовать хотя бы часть из STL (std::string, std::list, std::vector или std::set/map), то скорость компиляции уже заметно падает. А без STL я лично уже не хочу программировать на C++.

В то же время, компиляция библиотеки Mango (а это почти 200-ти файлов и больше 4Mb исходников) в release режиме занимает у меня на не очень мощном ноутбуке всего несколько (2-3) секунды. Очень впечатляет по первому разу. К тому же по своим возможностям D и C++ довольно-таки близки.

Ш>К сожалению, современный С++ страдает библиотечной болезнью. Т.е. когда пишутся безразмерные библиотеки "общего назначения", которые однако оказываюся плохо приложимыми для решения конкретных задач. Как результат -- и компилируется медленно, и испольняется тоже. Да ещё и тянет мегабайты мертвого кода.

Ага, а еще наровят все на шаблоннах сделать и совсем без cpp-файлов, чтобы каждый раз все перекомпилировалось...

Так что не смотря на довольно высокую скорость компиляции C++ файлов, есть и гораздо (очень гораздо) более быстро компилируемые языки. К сожалению для C++.

Здравствуйте, Константин Л., Вы писали:

КЛ>>>Хе-хе. Она мне в с# почти ни разу не пригодилась, не говоря уже о с++. Имхо рефлексия нужна там, где есть ошибки проектирования
КЛ>>> (сериализацию и т.п. в расчет не берем).

АХ>>Почему не берем? Это одна из базовых и необходимейших задач, а ее значение в свете веб-сервисов еще важнее. А также сюда же AOP, Unit Tests и еще много других нужных и полезных технологий.

КЛ>SOAP сериализация — да. Вэб-сервисы — частный случай.

Да это для начала. Применений рефлексии еще полно. Да хотя бы нормальный вывод сообщений об ошибках. __FILE__, __LINE__ недостаточно.

КЛ>Поддержка AOP должна быть на уровне языка.

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

АХ>>COM — это кроссязыковая технология и при этом такой жутик, что MS пришлось сделать .NET. При этом собственно изначально .NET возник из проекта по добавлению метаданных к C++ (здесь), но в процессе оказалось что для полноценной компонентной технологии этого мало.

КЛ>жутик? А может просто у некоторых людей проблемы с с++ и COM и им надо что-то попроще?

У самой MS с ним были проблемы, поэтому они и создали .NET.
Дело не в "попроще", а в "логичнее, надежнее и больше возможностей."

Для того, чтобы пользоваться COM мне еще надо всякие дурацкие нестандартные IDL-костыли вроде [in],[out] прикручивать, а потом пропускать через MIDL. Да и вообще даже с ATL с COM столько дурацкой тупой возни, да хотя бы с теми же GUIDами/CLSIDами, что застрелиться можно, а код замусорен макросами.

Ну и к тому же COM поддерживает очень малую часть возможностей C++.
Как мне с помощью COM любой стандартный контейнер типа std::vector передать ?
Или boost::lambda воспользоваться?
А могу ли я сделать шаблонную библиотеку?
Как насчет исключений?

КЛ> Ну так пусть юзают что попроще, но к нам сюда не лезут.

Мы уж лучше что помощнее. Попроще это к PHP-товарищам.

Здравствуйте, Андрей Хропов, Вы писали:

R>>Какие интересно задачи не позволяет решать С++? Имхо, если С++ сегодня не позволяет, то ни один язык сегодня не позволяет её решить.

АХ>В C++ даже нет такого базового свойства как рефлексия. Дальше можно не продолжать.

Это с каких это пор рефлексия — это базовое свойство?
Это все равно что в в каком-нть лохматом году начать говорить, что в Фортране нет такого базового свойства, как поддержки ООП.
Нормальная рефлексия характерна для современных языков да интерпретаторов типа TCL.
А метапрограммирование — штука сравнительно новая.
Хотя недооценивать ее, конечно же, нельзя, и комитет по стандартизации совершенно недвусмысленно указывает на свой интерес к ней (я процитирую, чтобы было яснее):

Not ready for C++09, but encourage work to continue
Papers in this category have been reviewed in EWG, and seen to solve real problems. While it is hoped that work will continue, they are not ready to be finalised in time for C++09. It is anticipated that this category will grow as time pressure restricts the feature list for C++09.

Reflective Metaprogramming in C++

Reflection in C++

Всего два пункта, и оба про рефлексию.

R>>Часто такими требованиями бывает портируемость не некую платформу, производительность, потребление памяти, доступ к аппаратному обеспечению, полный доступ к возможностям ос и т.д.

АХ>Это как раз к семантике (т.е. смыслу программы) никакого отношения не имеет. Это чисто технические подробности реализации.

а кто сказал, что требования к программам бывают толкьо семантическими? Наоборот, таких программ практически не бывает: все требуют чего-то специфического, и очень часто эти требования определяют язык разработки.

R>>Как бы это не было печально (или кому наоборот хорошо) и сегодня из-за семантической пропасти некое множество систем, написанных на языках _попроще_, или терпит крах или переписывается на С/С++...

АХ>Примеры?

У меня перед глазами прошло несколько экземпляров проприетарного банковского софта, в котором серверная часть была переписана с жавы на С++, обычно по соображениям производительности.

С остальным согласен.

You will always get what you always got
  If you always do  what you always did

Ш>К сожалению, современный С++ страдает библиотечной болезнью. Т.е. когда пишутся безразмерные библиотеки "общего назначения", которые однако оказываюся плохо приложимыми для решения конкретных задач. Как результат -- и компилируется медленно, и испольняется тоже. Да ещё и тянет мегабайты мертвого кода.
Не согласен. В С++ (по крайней мере, современном) очень часто приходится выбирать между скорости компиляции и скоростью исполнения в run-time. К примеру, ты пишешь класс строк — можно описать весь интерфейс в заголовке а всю имплементацию вынести в cpp. Компилироваться будет быстро, но зато поимеешь накладные расходы в run-time как минимум за счёт того что фунции не будут заинлайнены.

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

R>Всё ясно
R>Диплом/кандидатскую кто-то видимо защитил
Ничего тебе не ясно. Язык то развивается...
Уже и интеграция в студию работает лучше чем для С++. Подстказки для всего. Даже для кода сгенерированного макросами которые в немерле могут вобще все что можно сделать на платформе .НЕТ.

R>В общем несколько хватит фантации и какие требования.
Все эти способы я знаю и еще могу придумать... вот только нет способа такогоже простого, гибкого, надежного и масштабируемого как при использовании нормального метапрограммирования.

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

Еще раз перечитай мой первый пост в этой ветке. То сообщение на которое он был ответом. А потом перечитай свой пост.
Ведь ты же со мной согласен во всем кроме мелочей. Так что ты споришь?

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

WH>Еще раз перечитай мой первый пост в этой ветке. То сообщение на которое он был ответом. А потом перечитай свой пост.
WH>Ведь ты же со мной согласен во всем кроме мелочей. Так что ты споришь?

Главным образом я хочу получить ответ на свой вопрос:

R>>В-третьих, язык С++ очень мощный по выразительной мощности и по возможности абстрагироваться, и пакетировать функциональность (создавать повторноиспользуемые компоненты). По крайней мере из императивных языков.
WH>Раскажи это тем кто не пишет сложные кроссплатформенные системы на С++ ладно?

Вот тут не очень понял. Ты имеешь ввиду, что сложные кроссплатформенные системы нельзя писать на C++? Или что тем, кто не пишет сложных кроссплатформенных систем, C++ с его фичами не нужен?

поскольку твою фразу о разработке сложных кроссплатформенных систем я не понял

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

R>Вот, что из он заключает из этого:

R>

R>We need relatively complex language to deal with absolutely complex problems.

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

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

R>Никого же не удивляет, что очень сложно строить мосты и небоскрёбы.

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

Здравствуйте, Константин Л., Вы писали:

КЛ>ну как же тут без вас? Без вас уже ничего теперь не обходится.

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

R>Был свидетелем как переписывали с явы — не тянула требования работать на очень слабых машиных, которое вначале как-то не учли, а потом уже не смогли ничего сделать...
R>С явы и шарпа, слышал, переписывают, когда по портируемости не тянет.

Ыы??? Что ты имеешь в виду под портируемостью? Код переписывают с языка, который исполняеться на виртуальной машине и имеет сборщик мусора, на какой-то другой язык для увеличения портируемости?? Если ты скажешь, что этот "другой язык" — это С++, мои мозги вообще закипят! Как можно на плюсах писать программы, которые лучше "тянут" по портируемости чем Жава/дотНет???

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

Сложность штука сложная... Вот, например, сделать работающую версию довольно большого проекта за один месяц — сложная задача? И что сразу хвататься за ассемблер? Я так думаю, для каждой задачи — свои инструменты. А приоритеты (ограниченные ресурсы) в проекте могут быть разные: качество, надежность, время разаботки, цена, количество программистов, производительность системы... И наверное, решить все одним и тем же топором не получится.

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

G>Если ты скажешь, что этот "другой язык" — это С++, мои мозги вообще закипят!

Мне жаль твои мозги, но им суждено закипеть.
Посмотри, например, на список поддерживаемых платформ для ACE. Есть ли JVM для всех этих платформ?

И насколько, скажем портируемы приложения J2SE на тот же J2ME?

G>Как можно на плюсах писать программы, которые лучше "тянут" по портируемости чем Жава/дотНет???

С некоторым напряжением, но можно.
А если нужно дергать специфические фичи целевой платформы, то C++ выгодно отличается от Java и тем более, от .NET.
Легче писать портируемые программы, разве что, только на C. Но еще вопрос, будет ли легкость портируемости компенсировать сложность самой разработки по сравнению с C++.

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

G>Как можно на плюсах писать программы, которые лучше "тянут" по портируемости чем Жава/дотНет???
Это .NET портируемый? Ну портируйте кто нить что нить написанное хотяб под .NET 2.0 на линух.
Тогда как С++ проектов с никсов под вынь перетянуто множество.

АХ>>Примеры?

J>У меня перед глазами прошло несколько экземпляров проприетарного банковского софта, в котором серверная часть была J>переписана с жавы на С++, обычно по соображениям производительности.

Ну я тоже видел этот софт — и мне лично кажется, что эти "соображения производительности" — фигня
на постном масле. Едва ли там делался сильно глубокий анализ узких мест и как их устранять. Как известно,
у любой задачи есть простое и неправильное решение.

Если бы решение было действительно взвешенным, то сначала бы на С++ переписали критические места,
и это при том, что не удалось их оптимизировать без переписывания. HotSpot у Java работает вполне неплохо.

А между тем, я не знаю, какие именно ты проекты имеешь ввиду, но я прекрасно помню один проект на С++, у
который то тёк, то коредампился, и так — в течение длительного срока.

И плоды видимо переписывания с джавы, когда внутри метода сервера выделяется память, присваивается
указателю, разыменовывается и возвращается ссылка — я тоже видел.,

Кстати, еще вопрос как оно там было с масштабируемостью вообще. Есть мнение — что никак.

Один известный мне проект на C++ преимуществом многопроцессорности пользовался весьма слабо —
являя собой несколько жирных практически монолитных бинарников, которые едва ли утилизировали
все мощности сервера, и почти никак не масштабировался на несколько серверов.

Что же касается производительности... В одном известном тебе операторе сотовой связи,
большинство серверного софта, даже в части, связанной с телефонией, было написано на языках
высокого уровня — на Java и, немного, на C#.

И оно работает быстро, и при очень высокой нагрузке. И, что самое главное, в случае, когда производительности начинает не хватать — ставится новый сервер, вместо переписывания всего на C++, потом на C, потом на ASM, потом ...

Кстати, есть один большой показательный пример — из соображений "производительности" одну большую систему реализовали поверх С++ middleware, который по стилю очень похож на одну очень хорошо известную тебе систему.

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

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

J>С остальным согласен.

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

dmz>А между тем, я не знаю, какие именно ты проекты имеешь ввиду, но я прекрасно помню один проект на С++, у
dmz>который то тёк, то коредампился, и так — в течение длительного срока.
Да я смотрю тут вечер воспоминаний... Ну, я тож помню один проект на жаббе, который за пару лет разработки так и не научили работать с приемлемой скоростью и хавать не вообще всю свободную память.

dmz>Кстати, еще вопрос как оно там было с масштабируемостью вообще. Есть мнение — что никак.
Да, и не масштабировался он вообще никак. Даже удвоение оперативки от тормозов не спасло — он просто с радостно схавал дополнительную память и продолжил тормозюкать дальше. Заказчик был очень недоволен.

dmz>Один известный мне проект на C++ преимуществом многопроцессорности пользовался весьма слабо —
dmz>являя собой несколько жирных практически монолитных бинарников, которые едва ли утилизировали
dmz>все мощности сервера, и почти никак не масштабировался на несколько серверов.
Во во. Там тоже с этим не очень было. Просто в архитектуре масштабирование вообще никто не предусматривал. Да и софт был писан левой ногой.

dmz>В одном известном тебе операторе сотовой связи,
В городке N в компании M стоит софт, написанный на С== и который делает дело X. Так вот тот софт по производительности делает вообще всё, что когда либо писали и напишут
Настолько неаргументированно можно заявить вообще все что угодно.

dmz>... очень хорошо известную тебе систему.
Туды же... в качель, ага...

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

На любом языке можно писать плохо. Любую архитектуру можно спланировать наикривейшим способом. Язык то тут при чем?
Более того, приводя пример не мешало бы несколько конкретизировать и приводить хотя бы проверяемые данные. Потому как так можно написать все что угодно.

CC>В городке N в компании M стоит софт, написанный на С== и который делает дело X. Так вот тот софт по производительности делает вообще всё, что когда либо писали и напишут
CC>Настолько неаргументированно можно заявить вообще все что угодно.

А что вам — названия компаний и проектов привести? Вам названия проектов что-то скажут?
Jazzer знает, о чем я говорю И что проект A***a в ******** Bank(это он был переписан с Java из соображений производительности?) тёк и дампился долгое время — тоже Посмотрим на его возражения.

dmz>>При этом конечный результат не является чем-то запредельным по производительности, на фоне других приложений, реализованных на Java.
CC>Может просто надо было программистам руки выпрямить?

Ага — идите, выпрямляйте. Там как раз разработчиков C++ постоянно набирают, на этот проект как раз.
Хотите? Пишите в личку, выдам пароли и явки.

CC>На любом языке можно писать плохо. Любую архитектуру можно спланировать наикривейшим способом. Язык то тут при чем?

Мое утверждение: C++ не нужен для разработки серверов в 99.9% случаев. СУБД — это как раз оставшийся процент случаев. Разработка на нем дольше, сложнее, требует более высокой квалификации и не дает на этом классе задач никаких особенных преимуществ. С удовлетворением могу заметить, что эту точку зрения разделяют многие — например,
Ericsson.

Для системного программирования C++ тоже как-то не очень — что-то все больше С, тащить в ядра ОС или во встроенные устройства STL с boost пока решаются, видимо, только очень отдельные оригиналы.

Ну не страшно — ведь остается огромная ниша десктопного / прикладного софта, где относительно большая производительность и сравнительно небольшая прожорливость вполне себе факторы.

Врядли бы большинство пользователей были бы счастливы, если бы у них весь десктоп был написан на Java
Хотя с 2Gb памяти и 2GHz процами было бы нормально, наверное.

CC>Более того, приводя пример не мешало бы несколько конкретизировать и приводить хотя бы проверяемые данные. Потому CC>как так можно написать все что угодно.

Как вы собираетесь их проверять? Вам выдать исходники упомянутых проектов для самостоятельной сборки и проверки, что ли? Ну — какие подтверждения и чего именно нужны? Боюсь, что я могу только свидетелей привести.

Ну вот, например упомянутый мной пример С++ middleware. Очень красиво звучит — When High Performance Does Matter. На деле — 90% — маргетинговый буллщит, реальный опыт внедрения в одном из ведущих российских операторов сотовой связи — превышение сроков, бюджетов, огромная головная боль при разработке, долгий период нестабильности, дорогая поддержка — и в итоге всем ясно, что это уж никак не выигрывает у похожих по интенсивности и характеру нагрузке имеющихся решений на базе J2EE.

Нагрузка — десятки миллионов запросов в сутки и более. Казалось бы — high performance does matter, однако что-то не очень-то высокий перформанс тут — и аналогичные решения на Java, разработка и поддержка которых намного дешевле, справляются как минимум не хуже.

Кстати, хочу сказать, что я не призываю писать жесткий рилтайм на Java, однако же сомневаюсь, что его
пишут на C++.

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

dmz>Кстати, хочу сказать, что я не призываю писать жесткий рилтайм на Java, однако же сомневаюсь, что его
dmz>пишут на C++.

Таки пишут.
За счет того, что если C++ применять как C with classes, то писать на нем гораздо приятнее, чем на C.

А по поводу серверов -- в принципе согласен. Не зря же Java C++ в секторе server side значительно потеснила. Хотя в любой задаче есть свои исключения. И в большей степени качество и пр. параметры определяют не столько языки, сколько люди. А поскольку на подготовку нормального C++ программиста требуется гораздо больше времени и сил, то и результат получается соответствующий.

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

АХ>>>Примеры?

J>>У меня перед глазами прошло несколько экземпляров проприетарного банковского софта, в котором серверная часть была J>переписана с жавы на С++, обычно по соображениям производительности.

dmz>Ну я тоже видел этот софт — и мне лично кажется, что эти "соображения производительности" — фигня
dmz>на постном масле. Едва ли там делался сильно глубокий анализ узких мест и как их устранять. Как известно,
dmz>у любой задачи есть простое и неправильное решение.
dmz>Если бы решение было действительно взвешенным, то сначала бы на С++ переписали критические места,
dmz>и это при том, что не удалось их оптимизировать без переписывания. HotSpot у Java работает вполне неплохо.
я деталей не знаю, правда. Просто факт.
Ну и плюс в соседнем большом "фирмообразующем" проекте, о котором ты знаешь, ядро на плюсах, а гуй на жаве.

dmz>А между тем, я не знаю, какие именно ты проекты имеешь ввиду, но я прекрасно помню один проект на С++, у
dmz>который то тёк, то коредампился, и так — в течение длительного срока.

dmz>И плоды видимо переписывания с джавы, когда внутри метода сервера выделяется память, присваивается
dmz>указателю, разыменовывается и возвращается ссылка — я тоже видел.,
ну это вообще был код больных людей

dmz>Кстати, еще вопрос как оно там было с масштабируемостью вообще. Есть мнение — что никак.
dmz>Что же касается производительности... В одном известном тебе операторе сотовой связи,
dmz>большинство серверного софта, даже в части, связанной с телефонией, было написано на языках
dmz>высокого уровня — на Java и, немного, на C#.
dmz>И оно работает быстро, и при очень высокой нагрузке. И, что самое главное, в случае, когда производительности начинает не хватать — ставится новый сервер, вместо переписывания всего на C++, потом на C, потом на ASM, потом ...
все это — вопрос правильного проектирования, а не используемого языка. Если система сразу задизайнена по-человечески с расчетом на масштабируемость — она будет масштабируемой.
я вот сомневаюсь, что, скажем, гугль бегает на жаве.
Более того, я знаю фирмы, которые гоняют трафик, в чем-то сравнимый с сотовым — там все на С++ (преимущественно библиотека АСЕ плюс всякие бусты и прочая) — все летает и отлично масштабируется.

dmz>Один известный мне проект на C++ преимуществом многопроцессорности пользовался весьма слабо —
dmz>являя собой несколько жирных практически монолитных бинарников, которые едва ли утилизировали
dmz>все мощности сервера, и почти никак не масштабировался на несколько серверов.
Если мы говорим об одном и том же проекте — вспомни, в каком году он был написан


dmz>Кстати, есть один большой показательный пример — из соображений "производительности" одну большую систему реализовали поверх С++ middleware, который по стилю очень похож на одну очень хорошо известную тебе систему.
dmz>Так вот, в результате поимели: длительный период нестабильности софта, очень долгую (для подобного объема функционала) разработку, несколькикратное превышение сроков и бюджетов.

У меня есть контрпример — С++-проект, который решили переписать на жаве (чтоб масштабируемость и прочая бла-бла-бла), который, по веселому совпадению, граничил (в смысле интерфейса) с жавным проектом, у которого ядро переписывают на С++. Так вот это переписывание должно было быть закончено два(!) года назад. Сейчас его худо-бедно пытаются заюзать, но там сейчас вопрос больше в том, чтоб оно наконец хоть как-то корнректно зароаботало, на то, что оно во сколько-то раз (точно не знаю) медленнее, чем древняя и морально устаревшая сиплюсовая версия — об этом даже никто и не задумывается пока.

You will always get what you always got
  If you always do  what you always did

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

R>

R>We need relatively complex language to deal with absolutely complex problems.

R>Я с ним согласен.

Я с ним не согласен. Для решения сложных и запутанных задач нужен не сложный и запутанный язык, нужен мощный язык. Глупо отрицать, что C++ мощный язык. Но, во-первых, сегодня уже не самый мощный и выразательный, а, во-вторых, составляющая запутанности ограничивает его применение относительно оси сложности как снизу, так и сверху. Снизу порогом вхождения, сверху сложностью решения сложных задач.

R>То, что появится какой-то _простой_ язык, на котором можно будет научиться профессионально программировать на двух недельных курсах, и после этого создавать какие-то реальные приложения — это полная утопия и миф, который поддерживают компании, которые хотят впаривать якобы такие языки, и их поддерживают тупые менеждеры, которые верят, что они смогут понанимать дешёвых, неопытных программистов и таким образом достигнут высокой эффективности вложений.

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

R>Напоследок ещё одна цитата — просто очень понравиась:

R>

R>why do I see character echo delays in Word on my 2GHz, 2Gb computer? I didn’t see that on my editor on a shared 1MHz, 1Mb PDP11 25 years ago

А мне очень понравилось замечание WolfHound относительно этой цитаты

Угу вот только word написан на С/С++.