Здравствуйте, Nuzhny, Вы писали:
N>Этого никто не отрицает, язык не самый простой. N>Я в курсе, поэтому и на писал слово "может".
Это ключевой момент.
N>В твоём коде я не вижу и следа С, только С++. Ручное выделение памяти через new — это С? Ха-ха! Как раз твой пример отлично показывает достоинства С++.
Конкретно этот кусок по сути "Си с классами".
N>Это вообще из другой оперы, мы сейчас про обработку видео и изображений говорим.
Мне кажется мы не совсем понимаем друг друга. Мой посыл в том, что писать сложные алгоритмы проще на чистом Си. Нетривиальные конструкции языка тут будут только мешать добиться максимальной производительности.
Здравствуйте, Берсерк, Вы писали:
N>>Я в курсе, поэтому и на писал слово "может". Б>Это ключевой момент.
Тогда я не понял посыл.
N>>В твоём коде я не вижу и следа С, только С++. Ручное выделение памяти через new — это С? Ха-ха! Как раз твой пример отлично показывает достоинства С++. Б>Конкретно этот кусок по сути "Си с классами".
Ну, нет. Класс с аллокаторами, кучей шаблонов и т.п. — это С с классами только потому, что там есть указатели? Нет, нет, нет, тут С и близко нет.
Б>Есть и обработка изображений: Б>https://www.cairographics.org/manual/
Не обработка, но близко. И начали его писать 14 лет назад, ещё шаблонов в С++ не было. Пример не сильно показательный. Есть ещё ImageMagic — тоже на С, штука крутая, но тоже старовата, лет 30 уже библиотеке. И упомянутый ffmpeg тоже есть. Писать на С можно, но, как показывает практика, на С++ проще.
Б>Мне кажется мы не совсем понимаем друг друга. Мой посыл в том, что писать сложные алгоритмы проще на чистом Си. Нетривиальные конструкции языка тут будут только мешать добиться максимальной производительности.
Понимаем. Я как раз и говорю, что сложные алгоритмы писать на С++ проще, потому что он предоставляет зачастую бесплатные абстракции — те же шаблоны. Если не надо, то никто не заставляет плодить огромные иерархии классов с кучей виртуальных функций, которые могут просадить производительность по скорости и по памяти. Можно брать только подходящую задаче часть языка и писать.
Здравствуйте, Nuzhny, Вы писали:
N>Ну, нет. Класс с аллокаторами, кучей шаблонов и т.п. — это С с классами только потому, что там есть указатели? Нет, нет, нет, тут С и близко нет.
Мощь C++ не в последнюю очередь как раз в стандартной библиотеке. Если она не используется, не используются виртуальные методы то от С++ остается очень мало.
N>Понимаем. Я как раз и говорю, что сложные алгоритмы писать на С++ проще, потому что он предоставляет зачастую бесплатные абстракции — те же шаблоны. Если не надо, то никто не заставляет плодить огромные иерархии классов с кучей виртуальных функций, которые могут просадить производительность по скорости и по памяти. Можно брать только подходящую задаче часть языка и писать.
Ну вот и получается что зачастую подходящая часть языка довольно мала, то есть по факту используется "Си с классами". Шаблоны с перегрузкой операторов конечно выглядят заманчиво в плане реализации общих алгоритмов для разных типов данных, но на практике какие то сложные типы все равно будут требовать тонкой заточки или оптимизации. При этом нужно очень хорошо знать С++, а этого довольно часто нет в научной среде.
Здравствуйте, Берсерк, Вы писали:
Б>Мощь C++ не в последнюю очередь как раз в стандартной библиотеке. Если она не используется, не используются виртуальные методы то от С++ остается очень мало. Б>Ну вот и получается что зачастую подходящая часть языка довольно мала, то есть по факту используется "Си с классами".
От того, что в проекте используется лишь подмножество C++, используемое подмножество не перестает быть C++. По данному поводу уже было дано столько разъяснений, что позвольте просто оставить это здесь.
K>Серьезное утверждениие, хотелось бы услышать более развернутый ответ на чем выгодно писать ПО, для которого критично время отклика (latency) и высокая производительность.
K>Например: K>* Обработка видео в реальном времени. А пользователи хотят чтоб было fullHD и не лагало. K>* Трэйдинг. Трейдеры очень не любят когда они жмут кнопку купить, а поупка происходит по цене, которая сильно отличается от цены, которую они видят на эране. Есть еще алгоритмический трэйдинг, там все намного жестче (там 20 микросекунд это уже медленно). K>* Игрушки. Не тетрис на флеше, а настоящие 3D игры. Геймеры любят красивую графику, и не любят когда игра лагает.
но самый главный рынок таки в германии это производство где в автоматизации процессов именно latency
критично
Здравствуйте, Берсерк, Вы писали:
N>>Ну, нет. Класс с аллокаторами, кучей шаблонов и т.п. — это С с классами только потому, что там есть указатели? Нет, нет, нет, тут С и близко нет. Б>Мощь C++ не в последнюю очередь как раз в стандартной библиотеке. Если она не используется, не используются виртуальные методы то от С++ остается очень мало.
1. Стандартная библиотека там используется повсеместно. Всякие наборы точек, дескрипторов передаются и получаются как std::vector. Ну и другие штуки тоже используются.
2. Виртуальные методы? Ты это серьёзно? Покажи мне хоть один виртуальный метод в STL.
Б>Ну вот и получается что зачастую подходящая часть языка довольно мала, то есть по факту используется "Си с классами". Шаблоны с перегрузкой операторов конечно выглядят заманчиво в плане реализации общих алгоритмов для разных типов данных, но на практике какие то сложные типы все равно будут требовать тонкой заточки или оптимизации. При этом нужно очень хорошо знать С++, а этого довольно часто нет в научной среде.
Ничего себе мала! Ладно, дискуссию продолжать нет смысла, потому что у нас в корне разнится представление о том, что такое С++. С с классами и виртуальные методы — это всё где-то до 2003 года. Дальше главной фишкой стали шаблоны и compile-time абстракции. Именно это я считаю настоящим признаком наличия в коде С++ (современного С++). Это мощные и бесплатные абстракции, которые как раз и позволяют писать быстрый код.
Здравствуйте, PavelCH, Вы писали:
PCH>Добрый день! PCH>Интересует где на сегодня в производстве коммерческого ПО выгодно применять с++. Если есть возможность, опишите область применения и в двух-трех предложениях пример проекта/задачи чтобы она была понятна не только программисту, но и например прожект менеджеру.
— Модули, где нужна высока производительность кода. Например, очень мощная связка Python + C++. Т.е. делают сервисы на Python т.к. это простой, удобный, понятный язык для написания такой логики. А критичные модули реализуют на С++, дабы получить производительность. Потом эти модули дергают из питона. Опять же профит, что эти модули получаются небольшими. В машинном обучении такая связка сейчас очень распространена.
— Драйвера.
— Обычные бизнес-приложения. Сейчас мне кажется мало таких проектов осталось, много минусов у такого подхода. Так что эта ниша затухает.
— Приложения критичные по времени выполнения. Базы данных, например.
Если вам не так важно съэкономить несколько тактов процессора, но гораздо важнее скорость разработки и простота сопровождения в дальнейшем — имеет смысл смотреть на все остальное: .NET, Java, Go, Python и пр. и т.п.
Здравствуйте, so5team, Вы писали:
S>От того, что в проекте используется лишь подмножество C++, используемое подмножество не перестает быть C++. По данному поводу уже было дано столько разъяснений, что позвольте просто оставить это здесь.
Речь не про подмножество а про то, нужно ли в определенных проектах использовать C++. Принесет ли это больше пользы или вреда. По этому поводу разные мнения есть.
Здравствуйте, Nuzhny, Вы писали:
N>2. Виртуальные методы? Ты это серьёзно? Покажи мне хоть один виртуальный метод в STL.
Если STL не использует виртуальные методы это говорит о том, что они не являются важным инструментом C++?
N>Ничего себе мала! Ладно, дискуссию продолжать нет смысла, потому что у нас в корне разнится представление о том, что такое С++. С с классами и виртуальные методы — это всё где-то до 2003 года. Дальше главной фишкой стали шаблоны и compile-time абстракции. Именно это я считаю настоящим признаком наличия в коде С++ (современного С++). Это мощные и бесплатные абстракции, которые как раз и позволяют писать быстрый код.
Можно и не продолжать, если интереса нет. Шаблоны конечно мощные и бесплатные, но во многих случаях получается что бы избежать излишних вычислений приходится заниматься разными нетривиальными вещами типа expression templates. Вопрос не в том можно ли писать быстрый и эффективный код на С++ а в том стоит ли это делать. Стоит ли тратить время на тонкости языка только для того что бы код был читаемым (причем только С++ программистами) или стоит потратить это время на оптимизацию самого алгоритма? Вопрос приоритетов.
Здравствуйте, Берсерк, Вы писали:
N>>2. Виртуальные методы? Ты это серьёзно? Покажи мне хоть один виртуальный метод в STL. Б>Если STL не использует виртуальные методы это говорит о том, что они не являются важным инструментом C++?
По твоим словам — да. Могу привести цитату.
Б>Можно и не продолжать, если интереса нет. Шаблоны конечно мощные и бесплатные, но во многих случаях получается что бы избежать излишних вычислений приходится заниматься разными нетривиальными вещами типа expression templates. Вопрос не в том можно ли писать быстрый и эффективный код на С++ а в том стоит ли это делать. Стоит ли тратить время на тонкости языка только для того что бы код был читаемым (причем только С++ программистами) или стоит потратить это время на оптимизацию самого алгоритма? Вопрос приоритетов.
Да, стоит. Внутри того же OpenCV, который невольно стал примером тематической библиотеки на С++, тоже есть expression templates для матриц. Я могу написать читабельное выражение для любого математика типа: Y = A * X + B. И правая часть выполнится ОДНОЙ (!!!) специализированной функцией. Вот это и есть применение С++, которое улучшает понимание кода, делает его проще без ущерба для скорости.
Здравствуйте, Nuzhny, Вы писали: N>Здравствуйте, Берсерк, Вы писали:
N>>>Ну, нет. Класс с аллокаторами, кучей шаблонов и т.п. — это С с классами только потому, что там есть указатели? Нет, нет, нет, тут С и близко нет. Б>>Мощь C++ не в последнюю очередь как раз в стандартной библиотеке. Если она не используется, не используются виртуальные методы то от С++ остается очень мало.
... N>2. Виртуальные методы? Ты это серьёзно? Покажи мне хоть один виртуальный метод в STL.
По сути согласен, но в стандартной библиотеке виртуальные методы есть, а в STL нет.
Здравствуйте, PavelCH, Вы писали:
pik>>добавлю: практически везде в обалсти R&D PCH>Research & Development — не совсем ясно почему здесь применяют С++. Почему не языки более выского уровня?
Вообще-то С++ -- язык максимально высокого уровня для языков общего назначения (универсальных), выше только специализированные языки для программирования
специальных узких задач типа PowerBuilder, Oracle PL/SQL и т.п.
Здравствуйте, Берсерк, Вы писали:
Б>Мне кажется мы не совсем понимаем друг друга. Мой посыл в том, что писать сложные алгоритмы проще на чистом Си.
И будут эти алгоритмы работать только с void* без какой-либо проверки на этапе компиляции и оптимизации.
Б>Нетривиальные конструкции языка тут будут только мешать добиться максимальной производительности.
Нет, С++ дает возможность передать куда больше информации компилятору для проверок и оптимизации.
Здравствуйте, Skorodum, Вы писали:
S>И будут эти алгоритмы работать только с void* без какой-либо проверки на этапе компиляции и оптимизации.
С чего вдруг?
S>Нет, С++ дает возможность передать куда больше информации компилятору для проверок и оптимизации.
Каких конкретно?
S>Ради одного RAII стоит использовать С++, а не С.
Напомню тема разговора не что лучше C или C++ а стоит ли писать сложные вычисления (такие как декодирование видео) на C++ и если да, какие преимущества это дает.
Здравствуйте, Nuzhny, Вы писали:
N>С с классами и виртуальные методы — это всё где-то до 2003 года. Дальше главной фишкой стали шаблоны и compile-time абстракции. Именно это я считаю настоящим признаком наличия в коде С++ (современного С++). Это мощные и бесплатные абстракции, которые как раз и позволяют писать быстрый код.
Можно написать программу с простой и расширяемой архитектурой на "C с классами", а можно нагородить шаблонов и r-value reference, в которых сам автор через пол года не разберется, не получив никакого выигрыша. Первый вариант будет лучше.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Берсерк, Вы писали:
Б>Здравствуйте, Skorodum, Вы писали:
S>>И будут эти алгоритмы работать только с void* без какой-либо проверки на этапе компиляции и оптимизации. Б>С чего вдруг?
Как еще на С написать алгоритм который поддерживает пользовательский тип данных? Может авторы qsort в сишной библиотеки чего-то не знают?
S>>Нет, С++ дает возможность передать куда больше информации компилятору для проверок и оптимизации. Б>Каких конкретно?
Проверка типов, больше шанс на встраивание и прочие оптимизации. Вот пример сравнения qsort и std::sort. Можешь сам попробовать.
S>>Ради одного RAII стоит использовать С++, а не С. Б>Напомню тема разговора не что лучше C или C++ а стоит ли писать сложные вычисления (такие как декодирование видео) на C++ и если да, какие преимущества это дает.
Как минимум код красивее, лаконичнее и выразительнее. Вероятность ошибок из-за статической типизации и того же RAII сильно меньше. Возможности для оптимизации — выше.
Здравствуйте, Берсерк, Вы писали:
Б>Напомню тема разговора не что лучше C или C++ а стоит ли писать сложные вычисления (такие как декодирование видео) на C++ и если да, какие преимущества это дает.
Такая тема неявно предполагает, что использование C для сложных вычислений -- это прям таки общераспространенная практика. Между тем этот тезис отнюдь не является очевидным и не требующим доказательств. Посему интересно было бы послушать доводы за то, почему стоит писать сложные вычисления на C и какие преимущества это дает. За исключением довода "С++ ниасилили".
Здравствуйте, so5team, Вы писали:
S>Такая тема неявно предполагает, что использование C для сложных вычислений -- это прям таки общераспространенная практика. Между тем этот тезис отнюдь не является очевидным и не требующим доказательств. Посему интересно было бы послушать доводы за то, почему стоит писать сложные вычисления на C и какие преимущества это дает.
Нет, не предполагает. Из личного опыта, все с чем приходилось сталкиваться в области обработки сигналов/распознавания речи/кодеков было написано на Си. Единственно, это было довольно давно и мне самому было бы интересно узнать что поменялось с тех пор. Из преимуществ самое главное это простота языка, нет неявных вызовов функций, name mangling и других особенностей:
— Си функцию проще оптимизировать посмотрев в ассемблере какой код генерирует компилятор
— проще профилировать, нет неявных функций и сгенерированных имен
— код более понятен, нет перегрузки операторов
— проще профилировать использование памяти
S>За исключением довода "С++ ниасилили".
А зря, это очень важный фактор. В научной среде люди лучше потратят время на изучение нового алгоритма или на написание статьи, чем изучение нового сложного языка, который кроме качества самого кода никаких особых достоинств не принесет. Просто это несколько разные вещи, одно дело писать промышленную библиотеку, которую будут использовать сотни других программистов. А другое дело в течение месяца пытаться оптимизировать пару функций из нескольких десятков строк.
Здравствуйте, Skorodum, Вы писали:
S>Как еще на С написать алгоритм который поддерживает пользовательский тип данных? Может авторы qsort в сишной библиотеки чего-то не знают?
Типы и алгоритмы разные бывают. Далеко не всегда получается сделать алгоритм, который будет принимать пользовательские типы.
S>Проверка типов, больше шанс на встраивание и прочие оптимизации. Вот пример сравнения qsort и std::sort. Можешь сам попробовать.
Я знаю что быстрее, std::sort это любимый пример адептов шаблонов. Сортировка это слишком примитивный пример. Если задаться целью можно написать кастомизированную сортировку какого то сложного типа, которая будет значительно быстрее std::sort
S>Как минимум код красивее, лаконичнее и выразительнее. Вероятность ошибок из-за статической типизации и того же RAII сильно меньше. Возможности для оптимизации — выше.
Вероятность ошибок может и меньше но зато вероятность написать не оптимальный код выше.
