C++, область применения

Например игрушки.

Поддержка и доработка существующих проектов на С++ / проекты сильно завязанные на либы на С++ которым нет альтернативы на С. Все таки взаимодействие с либами на С++ из других языков заметно сложнее, чем с либами на С.

Я вот как раз хотел в топике написать что игры не обсуждаем, но подумал что никто о них говорить не будет.

> Поддержка и доработка существующих проектов на С++ / проекты сильно завязанные на либы на С++ которым нет альтернативы на С.

Не-не, это не то, я имею ввиду не поддержку, а разработку новых приложений.

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

почему, кстати? более чем навороченная и денежная индустрия.

// wbr

> почему, кстати? более чем навороченная и денежная индустрия.

Ну может потому что мне не интересно ее обсуждать? Ну да ладно, пока запишем под номером один "game development", еще есть?

> Ну может потому что мне не интересно ее обсуждать? Ну да ладно, пока запишем под номером один "game development", еще есть?

весь остальной development если не доказано обратного.

// wbr

Сформулирую вопрос иначе: область, в которой его удобно применять и в данный момент нет языков/платформ, которые были бы удобнее (эффективность, скорость разработки, простота поддержки) для этой области. Как-то так.

> Сформулирую вопрос иначе: область, в которой его удобно применять и в данный момент нет языков/платформ, которые были бы удобнее (эффективность, скорость разработки, простота поддержки) для этой области. Как-то так.

"удобнее" - это очень широкое и сугубо субъективное понятие. отталкиваться от него мягко говоря неконструктивно. что удобнее одному в одной ситуации может быть неудобно другому в другой. с такими предпосылками конструктива не будет, в лучшем случае лёгкий флейм уже на тысячный раз.

// wbr

> "удобнее" - это очень широкое и сугубо субъективное понятие.

Ну я же вроде дал довольно четкое определение удобства -- (эффективность выполнения х скорость разработки х простота поддержки).

> Ну я же вроде дал довольно четкое определение удобства -- (эффективность выполнения х скорость разработки х простота поддержки).

эффективность - понятие широкое. что конкретно под ним понимается?

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

// wbr

библиотеки графических тулкитов

> эффективность - понятие широкое. что конкретно под ним понимается?

"эффективность выполнения", скорость выполнения программы.

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

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

>Ну я же вроде дал довольно четкое определение удобства -- (эффективность выполнения х скорость разработки х простота поддержки).

Ещё цену разработчиков на конкретном языке неплохо учесть.

ИМХО начинать новый достаточно крупный проект на С++ сейчас неоправданно. Слишком затратно / трудоёмко.

>библиотеки графических тулкитов

Ни в коем случает. Ибо потом их можно будет использовать только из C++ (или писать _очень_ геморойную прослойку). Тут (ИМХО) рулит чистый C.

> Ещё цену разработчиков на конкретном языке неплохо учесть.

Не, это как раз таки в данном контексте не важно.

> начинать новый достаточно крупный проект на С++ сейчас неоправданно. Слишком затратно / трудоёмко.

Вот, а мне как раз и интересны задачи, которые кроме как на ц++ в данный момент ни на чем писать не стоит.

> Ещё цену разработчиков на конкретном языке неплохо учесть.

хорошее замечание. а так же их реальную доступность на рынке.

> ИМХО начинать новый достаточно крупный проект на С++ сейчас неоправданно. Слишком затратно / трудоёмко.

чрезвычайно спорное утверждение.

// wbr

> "эффективность выполнения", скорость выполнения программы.

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

// wbr

> Не, это как раз таки в данном контексте не важно.

это как раз очень важно и рассматривать вопрос в отрыве от реальной жизни - это вам на поля к сферическим коням в вакууме.

// wbr

> Ни в коем случает. Ибо потом их можно будет использовать только из C++ (или писать _очень_ геморойную прослойку). Тут (ИМХО) рулит чистый C.

биндинги Qt к python и java существуют и вполне нормально работают. что там происходит внутри и на сколько это было геморойно сделать авторам - вопрос мало интересный. они или есть и устраивают или же их нет.

// wbr

> это как раз очень важно и рассматривать вопрос в отрыве от реальной жизни - это вам на поля к сферическим коням в вакууме.

Дело в том что если принимать это во внимание, то есть только три-четыре языка C, Java, C++ и C#. Для выполнения проекта не нужны тысячи, нужно достаточное кол-во, а оно в разных ситуациях разное.

>биндинги Qt к python и java существуют и вполне нормально работают. что там происходит внутри и на сколько это было геморойно сделать авторам - вопрос мало интересный. они или есть и устраивают или же их нет.

Исключения только подтверждают правила. Сравните количество биндингов к Qt и к Tk (или GTK). Чувствуете разницу?

> (эффективность выполнения х скорость разработки х простота поддержки).

Ну так и скажи на каком месте С++ если мерять в баксо-часо-индусах.

Да кто его знает, место то сложно определить, можно сравнить, например для данной задачи c++ находится на N-ом месте, а Х на N - 1, Y на N + 1.

> Исключения только подтверждают правила. Сравните количество биндингов к Qt и к Tk (или GTK). Чувствуете разницу?

количество не означает качество. Qt биндится к мейнстриму и этого более чем. биндинги gtk, к примеру, к D интересуют лишь чрезвычайно малочисленную группу людей которой можно спокойно пренебречь.

// wbr

> Вот в том же ц++, на сколько я знаю, полностью абстрагироваться от низкоуровневых деталей нельзя

Нигде нельзя. Читать Джоэла.

> Например игрушки.

Никогда не понимал, что такого особенного в этих игрушках, что их только на C++ можно писать. Объясните, please. Или дело только в том, что программистов, знающих другие языки, в этой области нет?

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

Если ООП не нужен то проще писать на C. Если скорость не нужна то какой-нить интерпретируемый язык- прогать проще будет.

> Например игрушки.

Что игрушки пишутся на плюсах - это миф. Quake например на чистом С написан. А еще там свой скриптовый язык QuakeC. И вообще на С/С++ пишется только движок - логика и скрипты пишутся на чем то другом Lua/Python etc. А ресурсы и контент рисуются в соответствующих редакторах. Никто не пишет серьезные игры целиком на С++.

>количество не означает качество.

Не шлангуйте, пожалуйста. Количество говорит о лёгкости этой операции. И изначально речь шла о пригодности C++ для написания библиотек виджетов. В качестве аргумента непригодности я предложил "сложность написания биндингов к языкам, отличным от C++". Вы считаете что биндинги не нужны? Или что для библиотеки на C++ их писать не сложнее, чем для библиотеки на C?

>Qt биндится к мейнстриму и этого более чем.

Если Вы уже заговорили о мейнстриме -- покажите биндинги Qt к C# (.NET/Mono). Тот же Tk или Gtk можно без проблем привязать.

> Если нужен ООП и нужна скорость или низкое потребление ресурсов то C++ это то что нужно.

Это конь. Сферический. В вакууме. Конкретные области и задачи желательно приводить, где он объективно будет лучшим выбором.

Дык понятно, что не цпп единым. Но тот же Кармак вполне доволен DX9 и C++.

Это например мощные контроллеры с выводом графикой. На С горбатиться уже будет лень, для скриптов еще не так просторно по ресурсам, а С++ будет вполне себе.

> И вообще на С/С++ пишется только движок - логика и скрипты пишутся на чем то другом

Это понятно. Я как раз про core и говорю. Я помню, как писал свой движок по какой-то книге ("3D engine architecture" или что-то такое), только на Аде вместо C++. Первые 30% книги я вообще мог пропустить, так как там изобреталось то, что у меня и так уже было. Так уж C++ применим и необходим в этой области?

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

Есть, просто вопреки мнению klalafuda - нифига не бабластая эта область. Хреново там прогерам живется.

Кстати несмотря на то что quake а точнее id tech engine написан на С, Id tech 4 (Doom 3 / Quake 4) Кармак полностью перетащил на плюсы. Вот такая вот жопочка. Хотя имхо сильно зря - id шные творения всегда отличались красявостью и низкой требовательностью к ресурсам.

А С++ набрал у них популярность ввиду-того что большинство двигла написано на С++, и лишь редкие конторы пишут свои движки - в основном, покупают готовые с SDK. Ну lua там еще под сценарные скрипты применяется (а так вроде все). Если сильно в gamedev хочешь - сходи на gamedev.ru. Там тебе дадут краткое резюме на must have в этой области.

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

> Не-не, это не то, я имею ввиду не поддержку, а разработку новых приложений.

В наше время новые приложения практически никогда не начинают с нуля, всегда уже есть много-много готового кода. Почти всегда этот код на C++.

> почему, кстати? более чем навороченная и денежная индустрия.

Денежная? Да. Для издателей. А программахерам там всегда платили крохи, и всегда будут платить очень мало, туда в основном энтузиасты идут, им можно и не платить.

Только не это! Тулкиты на Цэ биндятся в любой язык и на любую VM, а быдлотулкиты на C++ применимы только в C++ без костылей.

> чрезвычайно спорное утверждение.

Абсолютно справедливое утверждение. Та же Java сейчас намного доступнее по всем параметрам.

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

Конечно существует. Разработка требовательных к производительности и объему памяти приложений на основе ООП-подхода.

> Никогда не понимал, что такого особенного в этих игрушках, что их только на C++ можно писать.

Особенного ровно то, что игрушки с нуля не пишут, а все доступные на рынке библиотеки (в средней игрушке их с десяток набирается) заточены под C++.

Вторая особенность - рынок труда в геймдеве, там очень мало кто знает что либо отничное от C++ и Lua.

> Абсолютно справедливое утверждение. Та же Java сейчас намного доступнее по всем параметрам.

высоконагруженный сервер обработки данных на java? только в страшном сне.

// wbr

Не разумно. Для таких задач разумно использовать настоящий высокоуровневый язык (например, Mathematica), из которого генерить код на языке эффективном (Фортран или plain C). Для этих задач C++ абсолютно неуместен, поскольку абстракции там даются только ценой производительности.

> высоконагруженный сервер обработки данных на java? только в страшном сне.

Erlang тогда. Только не C++.

> Разработка требовательных к производительности и объему памяти приложений на основе ООП-подхода.

Чушь свинячья. С высокими требованиями к объёму памяти и производительностью и Java-приложения выступать умеют.

А вот в условиях жестких ограничений по памяти и производительности C++ очень неэффективен.

> Для новых проектов C++ разумно использовать в числодробительных задачах сводящихся к высокоуровневым абстракциям (нейронные сети, генетические алгоритмы и т. п.)

В подобных задачах, возможно, новые проекты начинать на инструментах у которых неплохо с распараллеливанием, в т. ч. и автоматическим, erlang (у которого сейчас все неплохо), haskell, у которого в будущем большие перспективы именно с автоматическим распараллеливанием. Даи и сложные алгоритмы на том же хаскеле несравнимо легче реализовывать, чем на ц++.

>Для этих задач C++ абсолютно неуместен, поскольку абстракции там даются только ценой производительности

У меня Stepanov test на Intel compiler показывал что накладные расходы на абстракцию минимальны, в пределах 10%.

Это если херовая абстракция. А попробуй хотя бы те же матрицы реализовать ЭФФЕКТИВНО, так, чтобы и код высокоабстрактным был, и производительностью платить не приходилось.