B>Блистательная , шикарная CORBA .
Я правильно понял? Использование здесь с++ заключается в написания отдельных компонентов по этой спецификации на с++ и использовать их в распределенных системах наряду с другими?
Здравствуйте, PavelCH, Вы писали:
AG>>b) Вычислительные алгоритмы и приложения с ними (для разных областей народного хозяйства); AG>>c) Задачи математического моделирования;
PCH>Почему в этих пунктах выгодно использовать с++, а не другие языки?
Для этих применений очень часто важен фактор эффективного использования вычислительных ресурсов.
Вот примеры:
Вычислительная, модная нынче задача (майнить криптовалюты) применяя C++ получим результат быстрее,
чем это было бы применяя Java или C#: https://habrahabr.ru/post/183536
Насчёт математического моделирования: приходится обрабатывать большие объёмы данных, если делать это на современных языках,
то моделирование займёт слишком много времени.
Пример математического моделирования компьютерной сети: https://lvee.org/en/reports/LVEE_2010_31
D>Angry Birds, Cut the Rope, Doodle God смотрят на тебя с недоумением. D>Монетизация ортогональна языку программирования.
Вы будете смеяться, но инвесторы стартапов (не бейкеры с кикстартера, а фирмы-акселераторы) осторожно интересуются а как "вы там пишете игру". И если не услышат в ответ знаковые слова аля "Unity" или "Unreal Engine", то скорее всего подумают дважды прежде чем вложить свои деньги.
Здравствуйте, Nuzhny, Вы писали:
N>Пример того же ffmpeg показывает, что такой подход может быть весьма ущербным. Это жуткая штука с ООП на С и утечками памяти. ООП на С! Им нужны абстракции! Но они получились уродскими, потому что язык не может лучше.
Может быть, а может и не быть. Примеров ущербного софта на С++ тоже не мало.
N>С другой стороны, есть OpenCV, который от C API перешёл на С++ API и весь был переписан на С++. При этом НЕ замедлился, а работа с ним заметно упростилась как раз благодаря новым уровням абстракции. Его из плюсов использовать практически так же легко, как и из Питона с его мощными scipy и numpy. Так что тут ты не прав.
Я правильно понимаю, что после переписывания он не стал быстрее ("не замедлился" ты подаешь как успех) а лишь стал удобнее в использовании (скорее всего для программистов С++)?
Здравствуйте, Pzz, Вы писали:
Pzz>На мой взгляд, нигде. Но меня не поймут и наставят минусов
C++ это по сути более удобный Си. Там где применяется Си можно успешно применять и С++, при условии понимания его работы и наличия качественного компилятора.
Здравствуйте, PavelCH, Вы писали: PCH>Вы будете смеяться, но инвесторы стартапов (не бейкеры с кикстартера, а фирмы-акселераторы) осторожно интересуются а как "вы там пишете игру". И если не услышат в ответ знаковые слова аля "Unity" или "Unreal Engine", то скорее всего подумают дважды прежде чем вложить свои деньги.
А под Unreal Engine не на С++ случаем пишут?
Здравствуйте, PavelCH, Вы писали: PCH>На сегодня игрушки выгодно разрабатывать с Unity. А там C# или JavaScript.
Игрушки сегодня выгодно разрабатывать на всем подряд — даже на флеше люди зарабатывают до сих пор. И вы не ответили на мой вопрос выше — на каком языке разрабатывают под UE4?
Здравствуйте, PavelCH, Вы писали: PCH>На с++. Но вот в чем его преемущество перед той же юнити не пойму. Вы знаете?
В гугле полно информации. Я не пользуюсь ни одним, ни другим инструментом, но сам факт того, что UE, CryEngine, и прочие движки на С++ широко используется в играх и, эти игры приносят хорошие деньги, должен ответить на ваш вопрос. Выгодно делать игры на С++? ВЫГОДНО!
Здравствуйте, Берсерк, Вы писали:
Б>Я правильно понимаю, что после переписывания он не стал быстрее ("не замедлился" ты подаешь как успех) а лишь стал удобнее в использовании (скорее всего для программистов С++)?
По факту — он ускорился. Но там одновременно и массово внутренность многих функций была переписана на SSE, AVX, NEON.
Удобнее использовать, кстати, стало всем. Появились нормальные биндинги на Питон и Java. Существует постоянное сторонее API для С# — Emgu CV. Если ранььше библиотека была достаточно страшной со всех сторон (во времена Интела), глючила безбожно, текла память, то сейчас это очень качественная вещь. Пользоваться реально удобно.
Здравствуйте, Nuzhny, Вы писали:
N>По факту — он ускорился. Но там одновременно и массово внутренность многих функций была переписана на SSE, AVX, NEON.
Ну то есть ускорился не за счет переписывания на С++?
N>Удобнее использовать, кстати, стало всем. Появились нормальные биндинги на Питон и Java. Существует постоянное сторонее API для С# — Emgu CV. Если ранььше библиотека была достаточно страшной со всех сторон (во времена Интела), глючила безбожно, текла память, то сейчас это очень качественная вещь. Пользоваться реально удобно.
Я все ещё не могу понять, как на это повлиял именно C++?
В целом мне кажется Pzz прав насчет того, что какие то критичные по времени выполнения вещи стоит писать в процедурном стиле с использованием собственных специально оптимизированных под задачу структур данных. В таком подходе, скорее всего, многие возможности С++ не будут использоваться.
Здравствуйте, AlexGin, Вы писали:
AG>Вот примеры: AG>Вычислительная, модная нынче задача (майнить криптовалюты) применяя C++ получим результат быстрее, AG>чем это было бы применяя Java или C#: https://habrahabr.ru/post/183536
Алло Алекс!
Ты что издеваешься? В этой статейке нет ничего про майнинг. Не говоря уже о C# и Java. Только время потерял.
Здравствуйте, Берсерк, Вы писали:
N>>По факту — он ускорился. Но там одновременно и массово внутренность многих функций была переписана на SSE, AVX, NEON. Б>Ну то есть ускорился не за счет переписывания на С++?
Нет, не за счёт. Я и не писал, что за счёт, ты следишь за беседой?
Б>Я все ещё не могу понять, как на это повлиял именно C++?
С++ сделал возможность резко расширить библиотеку функциями и алгоритмами, при этом использование её стало проще. Раньше основным типом данных был уродский IplImage, с которым было работать неудобно. Теперь это cv::Mat (и не только, там несколько разных Mat). Не непонятный самописный cvSeq, а std::vector. И т.д. и т.п. Смартпоинтеры, интерфейсы, шаблоны, перегрузка функций. Раньше надо было писать кучу портянок сервисного кода, а стало возможно описывать практически только алгоритм. И после перехода на С++ начался активный рост библиотеки, она стала де-факто стандартом в области компьютерного зрения. И это неоспоримый факт — Khronos в своих стандартах ссылается на неё тоже.
Далее внутренности функций активно переписываются на SSE, AVX, NEON. Nvidia своими силами делает CUDA-версии большинства алгоритмов, Интел и АМД своими силами — OpenCL версии. Также Nvidia делает форк под Тегру.
Это всё произошло на моих глазах, я пользовался OpenCV ещё с версий 0.х, что-то фиксил, что-то находил и говорил разработчикам. Так вот до перехода на С++ библиотека была глючной поделкой от Интел с утечками памяти, а после перехода на С++ стала чуть ли не отраслевым стандартом. И даже интеловское IPP практически загнулось на её фоне и теперь предлагается бесплатно в качестве ускорения некоторых частей OpenCV.
Тут же: ccv, написанная на С, загнулась, хотя содержала очень быстрые реализации многих популярных алгоритмов.
Библиотека dlib — эта уже на С++, развивается, во многих областях конкурирует с OpenCV.
Так что в этой области С библиотеки по всем фронтам уступает место С++ библиотекам.
Б>В целом мне кажется Pzz прав насчет того, что какие то критичные по времени выполнения вещи стоит писать в процедурном стиле с использованием собственных специально оптимизированных под задачу структур данных. В таком подходе, скорее всего, многие возможности С++ не будут использоваться.
А я думаю, что не прав. С++ с его шаблонами даёт бесплатные абстракции, которые зачастую ещё и быстрее. Яркий пример — функторы вместо указателей на функцию.
Плюс есть ещё много довольно сложных вещей, типа стабилизации видео. Это что-то типа пайплайна, который содержит в себе вызов нескольких алгоритмов (поиск движения, модель движения, компенсация, warp and fuse — не знаю, как правильно перевести). И у всех этих семейств алгоритмов есть множество реализаций, каждая из которых зависит от набора своих параметров. И на С++ код, использующий стабилизацию, выглядит достаточно компактно и красиво. НА С этот же код был до того громоздким, что глаз просто терялся в деталях, очень трудно было разглядеть сам алгоритм за кучей мишуры. Вот в таких местах очень часто и появляются ошибки. Или за сложностью реализации теряется суть алгоритма.
Можно было бы на С написать это лучше? Да, можно. Но тогда пришлось бы вручную делать всё то, что уже есть в другом языке, который по всем фронтам получается лучше.
Здравствуйте, Nuzhny, Вы писали:
N>Нет, не за счёт. Я и не писал, что за счёт, ты следишь за беседой?
Слежу, напомню с чего она началась:
K>* Обработка видео в реальном времени. А пользователи хотят чтоб было fullHD и не лагало.
Полагаю, на чистом Си. Сложные абстракции в такой задаче не нужны, и только мешаются.
N>Так что в этой области С библиотеки по всем фронтам уступает место С++ библиотекам.
Мне сложно тут что-то комментировать так как с OpenCV дела не имел. Но это все равно выглядит как ошибки проектирования изначальной библиотеки. Потом пришли более грамотные специалисты и сделали все красиво, а C++ тут уже был вторичен, на мой взгляд.
N>А я думаю, что не прав. С++ с его шаблонами даёт бесплатные абстракции, которые зачастую ещё и быстрее. Яркий пример — функторы вместо указателей на функцию.
Вот про "зачастую ещё и быстрее" и хотелось бы услышать поподробнее. Чем функтор в плане производительности лучше указателя на функцию?
N>Можно было бы на С написать это лучше? Да, можно. Но тогда пришлось бы вручную делать всё то, что уже есть в другом языке, который по всем фронтам получается лучше.
И на С++ точно так же придется писать свои структуры данных со своим ручным выделением памяти. Стандартные средства C++ не дают достаточного контроля над тем как и когда выделяется память а это очень важно для производительности. Так же все неявные вызовы конструкторов/деструкторов нужно отслеживать. Скажу так, на С++ писать высокопроизводительный софт писать будет даже сложнее, чем на Си, потому что нужно очень хорошо понимать весь тот скрытый код, который идет в качестве "оплаты" за удобное использование.
Здравствуйте, Берсерк, Вы писали:
Б>Слежу, напомню с чего она началась: Б>
K>>* Обработка видео в реальном времени. А пользователи хотят чтоб было fullHD и не лагало.
Б>Полагаю, на чистом Си. Сложные абстракции в такой задаче не нужны, и только мешаются.
Именно. На С++ можно писать, не лагает, абстракции нужны. Причём нужны всем: ffmpeg, gstreamer, DirectShow — как без абстракций строить пайплайны с фильтрами?
Б>Мне сложно тут что-то комментировать так как с OpenCV дела не имел. Но это все равно выглядит как ошибки проектирования изначальной библиотеки. Потом пришли более грамотные специалисты и сделали все красиво, а C++ тут уже был вторичен, на мой взгляд.
Вот и нет, разработку продолжала та же команда, что и раньше, они ушли из Интела и основали Itseez, а через 10 лет Интел купила компанию вместе с сотрудниками. Только возникло богатое комьюнити из самых разнообразных разработчиков: учёные, инженеры, крупные корпорации.
Б>Вот про "зачастую ещё и быстрее" и хотелось бы услышать поподробнее. Чем функтор в плане производительности лучше указателя на функцию?
Тем что может инлайниться.
Б>И на С++ точно так же придется писать свои структуры данных со своим ручным выделением памяти. Стандартные средства C++ не дают достаточного контроля над тем как и когда выделяется память а это очень важно для производительности. Так же все неявные вызовы конструкторов/деструкторов нужно отслеживать. Скажу так, на С++ писать высокопроизводительный софт писать будет даже сложнее, чем на Си, потому что нужно очень хорошо понимать весь тот скрытый код, который идет в качестве "оплаты" за удобное использование.
Примеры в студию! Область моей компетенции говорит об обратном. Даже мультимедиа драйвер в АМД писался на С++.
Здравствуйте, Nuzhny, Вы писали:
N>Именно. На С++ можно писать, не лагает, абстракции нужны. Причём нужны всем: ffmpeg, gstreamer, DirectShow — как без абстракций строить пайплайны с фильтрами?
Писать можно, но нужно очень хорошо понимать тонкости языка.
N>Тем что может инлайниться.
//! helper fields used in locateROI and adjustROIconst uchar* datastart;
const uchar* dataend;
const uchar* datalimit;
//! custom allocator
MatAllocator* allocator;
//! and the standard allocatorstatic MatAllocator* getStdAllocator();
static MatAllocator* getDefaultAllocator();
static void setDefaultAllocator(MatAllocator* allocator);
Нет ни std::vector ничего то подобного. Ручное выделение памяти. Ещё раз повторю тезис — писать можно и на C++, но нужно очень хорошо понимать стоимость различных конструкций и знать когда их стоит применять а когда нет. И когда речь идет о реализации сложных алгоритмов такие тонкости могут только мешать. Именно это и был начальный посыл разговора.
Здравствуйте, PavelCH, Вы писали:
K>>* Трэйдинг. Трейдеры очень не любят когда они жмут кнопку купить, а поупка происходит по цене, которая сильно отличается от цены, которую они видят на эране. Есть еще алгоритмический трэйдинг, там все намного жестче (там 20 микросекунд это уже медленно). PCH>Не согласен. Если брать высоконагруженные системы, такие как amazon, которых единицы в мире, то там возможно. И то, С++ слишком неудобен в синтаксисе. Логику придется писать на каком-то скриптовом языке. Если речь идет об остальных системах, то опять же, есть тот же 1С, Java.
Я имел ввиду не интернет магазин, а биржевую торговлю. В некоторых случаях тут выгодно (именно выгодно) писать и логику на С++.
K>>* Игрушки. Не тетрис на флеше, а настоящие 3D игры. Геймеры любят красивую графику, и не любят когда игра лагает. PCH>На сегодня игрушки выгодно разрабатывать с Unity. А там C# или JavaScript.
Ну, может быть, если надо побыстрому выпустить какую-то игрушку, это действительно выгодно. Но помоему все действительно крутые (с крутой графикой) игры написаны на плюсах.
Здравствуйте, Берсерк, Вы писали:
N>>Именно. На С++ можно писать, не лагает, абстракции нужны. Причём нужны всем: ffmpeg, gstreamer, DirectShow — как без абстракций строить пайплайны с фильтрами? Б>Писать можно, но нужно очень хорошо понимать тонкости языка.
Б> //! helper fields used in locateROI and adjustROI
Б> const uchar* datastart;
Б> const uchar* dataend;
Б> const uchar* datalimit;
Б> //! custom allocator
Б> MatAllocator* allocator;
Б> //! and the standard allocator
Б> static MatAllocator* getStdAllocator();
Б> static MatAllocator* getDefaultAllocator();
Б> static void setDefaultAllocator(MatAllocator* allocator);
Б>
Б>Нет ни std::vector ничего то подобного. Ручное выделение памяти. Ещё раз повторю тезис — писать можно и на C++, но нужно очень хорошо понимать стоимость различных конструкций и знать когда их стоит применять а когда нет. И когда речь идет о реализации сложных алгоритмов такие тонкости могут только мешать. Именно это и был начальный посыл разговора.
В твоём коде я не вижу и следа С, только С++. Ручное выделение памяти через new — это С? Ха-ха! Как раз твой пример отлично показывает достоинства С++.
смотрят на тебя с недоумением.
