Здравствуйте, vsb, Вы писали:
vsb>Я думал ffmpeg на С написан. Ну значит заменили rust на rust (на resvg).
vsb>Выходит, что софта на С/С++ уже и не осталось, всё переписали. Ну и слава богу.
Какие погоды у вас там, в стране розовых поней, стоят нонче?
Здравствуйте, Артём, Вы писали:
S>>прирост производительности там был из-за использования других алгоритмов
Аё>Если у языка C++ тупиковый противоречивый дизайн, то что ожидать от его религиозных последователей?
В FFMPEG (чистый Си) была либа на Rust-е вместо которой написали другую либу на Rust-е и в этой другой либе применили другие алгоритмы, что и привело к увеличению производительности. В упорной борьбе Rust победил у Rust-а.
Здравствуйте, Артём, Вы писали:
Аё>Я просто не представляю, какое место в современной картине мира у состима с его плюсами.
Конкретно у so5team -- это различный middleware, вроде упоминавшегося здесь прокси-сервера envoy.
И это только потому, что so5team не интересно влазить в чисто системную разработку (как CreatorCray), в чисто вычислительные задачи (как Nuzhny), в СУБД, в игрострой и т.д., и т.п.
Аё>Суппортить древний mfc-й софт, которые еще не успели переписать на html5?
С месяц назад предлагали поучаствовать в доработках открытой версии СУБД Greenplum. Там часть на C++, часть на чистом Си. Та часть, которая на C++, ну очень уж в духе MFC (такое ощущение, что MFC-шный кодстайл был специально использован).
По качеству кода очень даже неплохо все там выглядело. Не похоже на то "легаси" про которое говорят с отрицательными конотациями. И задача сама по себе такая, которая никогда не будет решаться ни JS, ни на Go, ни даже Java или C#. Либо чистый Си, либо С++, либо Rust. Но, скорее всего, именно Си и С++, т.к. искать на рынке толковых Rust-овиков сейчас сложнее, чем сишников или плюсовиков.
Здравствуйте, Nuzhny, Вы писали:
Аё>>Пакеты для питона.
N>У них есть полноценное C++ API, поэтому не для Питона. Эта область фундаментально вся написана на плюсах, я тебе уже приводил множество примеров не только этих, но и других библиотек. Так оно получилось, что вычислений очень много и делать их надо быстро, поэтому тут С++ монополист и пока тот же Rust близко не подходит.
Подожди. Программтсты на тензорфло не используют плюсы, они юзают именно через питон. А еще есть tensorfloJS- я так предполагаю, что оно часть ядра таки на плюсах, но приготовлено в webassembly. И это вот из ноды и в браузере доступно.
Так что тензорфло, как предметная область и экосистеиа- это не плюсы. Хотя оно написано на плюсах. Но можно и нужно на C и Fortran.
Бизнес логика, микросервисы, гуя и т.п. плюсам не место.
Здравствуйте, Артём, Вы писали:
Аё>Так что тензорфло, как предметная область и экосистеиа- это не плюсы. Хотя оно написано на плюсах. Но можно и нужно на C и Fortran.
На счет "нужно" -- это ты еще потрудись доказать.
А на счет "можно" -- попробуй подсчитать в деньгах сколько будет стоить разработка на чистом Си в сравнении с C++.
Аё>Бизнес логика,
"Бизнес-логика" она у каждой задачи разная. В складском учете своя, в ядре антивируса своя, в кэширующем прокси-сервере своя. Так что это всего лишь красивый базз-ворд, не больше.
Аё>микросервисы,
Оно бы можно было бы даже и поверить если бы не одно но: мы, в своем условном Бобруйске, сделали маленькую библиотеку для организации HTTP-входа в C++ные приложения и эта библиотека используется разными людьми в разных проектах уже лет пять как, в том числе и для микросервисов. И наша поделка всего лишь одна из, далеко не самая раскрученная и далеко не самая популярная.
Так что микросервисы на C++ -- это не просто норм, это вполне себе реальная практика. Как раз в духе микросервисного подхода, когда не суть важно, на чем именно пишется конкретный микросервис.
Аё>гуя
В некоторых задачах для GUI не берут ничего кроме подхода IMGUI. И здесь C++ (например, в виде DearIMGUI) нехило так рулит и педалит, заруливая все остальное в ноль.
Пример такой задачи в обсуждении уже DiPaolo показал.
Здравствуйте, so5team, Вы писали:
Аё>>Я просто не представляю, какое место в современной картине мира у состима с его плюсами.
S>Конкретно у so5team -- это различный middleware, вроде упоминавшегося здесь прокси-сервера envoy.
Которое лучше переписать на Go.
S>И это только потому, что so5team не интересно влазить в чисто системную разработку (как CreatorCray), в чисто вычислительные задачи (как Nuzhny), в СУБД, в игрострой и т.д., и т.п.
Чиста системное это C. Не смотри что крейтор- он нитакой, в яблочной компании. Чиста вычисления- матлаб, фортран и т.п. Чиста субд- ну там да, плюсы логичны. Хотя извращенцы и на жаве пилили.
Игрострой- там lua.
S>С месяц назад предлагали поучаствовать в доработках открытой версии СУБД Greenplum. Там часть на C++, часть на чистом Си. Та часть, которая на C++, ну очень уж в духе MFC (такое ощущение, что MFC-шный кодстайл был специально использован).
Т.е. кал мамонта.
S>По качеству кода очень даже неплохо все там выглядело.
Если тебе нравится кал мамонта.
Приложениями ты и не занимаешься, но топишь за плюсы. Тогда как пользуешься интернет-кабинетиком для банка, а не устанавливпешь мфс-ное говнище клиент банка.
Здравствуйте, Артём, Вы писали:
S>>Конкретно у so5team -- это различный middleware, вроде упоминавшегося здесь прокси-сервера envoy. Аё>Которое лучше переписать на Go.
Попробуй. Обкакаешься, мягко говоря.
S>>И это только потому, что so5team не интересно влазить в чисто системную разработку (как CreatorCray), в чисто вычислительные задачи (как Nuzhny), в СУБД, в игрострой и т.д., и т.п. Аё>Чиста системное это C.
Уже давно нет.
Аё>Чиста вычисления- матлаб,
Это до тех пор, пока ты модельки разрабатываешь и тебе для этого достаточно мощности одного десктопа. Когда дело доходит до вычислительных кластеров в сотни тысяч ядер, там не матлаб, насколько мне известно.
Аё>фортран и т.п.
Фортран да, все еще. И он нас с тобой там переживет.
А вот ты попробуй развернуть "и т.п." в реальный список и увидишь, что там только Си и С++. Может быть когда-нибудь какая-нибудь Julia доберется.
Аё>Игрострой- там lua.
Даже я, очень далекий от игростроя человек, наслышан об активнейшем использовании C/C++ для написания движков, поверх которых уже Lua или что-то еще используется для скриптования. Т.е. без харкорного C++ в серьезных играх на Lua ты никуда не удешь.
S>>С месяц назад предлагали поучаствовать в доработках открытой версии СУБД Greenplum. Там часть на C++, часть на чистом Си. Та часть, которая на C++, ну очень уж в духе MFC (такое ощущение, что MFC-шный кодстайл был специально использован). Аё>Т.е. кал мамонта.
Ты в очередной раз звездишь о том, в чем не разбираешься.
Аё>Приложениями ты и не занимаешься, но топишь за плюсы.
Будь точнее в формулировках, "приложения" -- это что? Можно ли envoy считать приложением?
Аё>Тогда как пользуешься интернет-кабинетиком для банка
И в инфраструктурной части этого кабинетика будет полно кода на плюсах.
Здравствуйте, so5team, Вы писали:
S>В некоторых задачах для GUI не берут ничего кроме подхода IMGUI.
В первый раз слышу. Спасибо, загуглил.
Какое у imgui преимущество перед Angular, React, Flutter, Blazor для апликух? Даже и Flutter с Blazor имеют (имели) проблемы. Элементарно, навигация с клавиатуры- табы, стрелки, text to speach из коробки с html5.
Здравствуйте, so5team, Вы писали:
S>>>Конкретно у so5team -- это различный middleware, вроде упоминавшегося здесь прокси-сервера envoy. Аё>>Которое лучше переписать на Go.
S>Попробуй. Обкакаешься, мягко говоря.
Ты просто не умеешь готовить.
S>>>И это только потому, что so5team не интересно влазить в чисто системную разработку (как CreatorCray), в чисто вычислительные задачи (как Nuzhny), в СУБД, в игрострой и т.д., и т.п. Аё>>Чиста системное это C.
S>Уже давно нет.
Пусть aik отпишется. Там вроде linux kernel.
Аё>>Чиста вычисления- матлаб,
S>Это до тех пор, пока ты модельки разрабатываешь и тебе для этого достаточно мощности одного десктопа. Когда дело доходит до вычислительных кластеров в сотни тысяч ядер, там не матлаб, насколько мне известно.
Ну другое что-то. Не плюсы.
Аё>>фортран и т.п.
S>Фортран да,
Хоть тут согласился
S>Даже я, очень далекий от игростроя человек, наслышан об активнейшем использовании C/C++ для написания движков,
Ок. Хром наптсан на C++, значит весь веб, весь жаваскрипт- это сиплюсы. Все сиплюсники получается
S>Ты в очередной раз звездишь о том, в чем не разбираешься.
мфц стиль маст дай.
Аё>>Приложениями ты и не занимаешься, но топишь за плюсы.
S>Будь точнее в формулировках, "приложения" -- это что? Можно ли envoy считать приложением?
Application.
Аё>>Тогда как пользуешься интернет-кабинетиком для банка
S>И в инфраструктурной части этого кабинетика будет полно кода на плюсах.
И еще на кремнии, меди, алюминии тоже.
S>А на счет "можно" -- попробуй подсчитать в деньгах сколько будет строить разработка на чистом Си в сравнении с C++.
+ поддержка
S>"Бизнес-логика" она у каждой задачи разная. В складском учете своя, в ядре антивируса своя, в кэширующем прокси-сервере своя. Так что это всего лишь красивый базз-ворд, не больше.
+++
S>Оно бы можно было бы даже и поверить если бы не одно но: мы, в своем условном Бобруйске, сделали маленькую библиотеку для организации HTTP-входа в C++ные приложения и эта библиотека используется разными людьми в разных проектах уже лет пять как, в том числе и для микросервисов. И наша поделка всего лишь одна из, далеко не самая раскрученная и далеко не самая популярная.
Я в одном проекте использовал как раз именно эту библиотеку для сервера на плюсах Решение было не мое, проект уже достался с такой архитектурой. Всем этим пользовался веб ГУЙ на реакте. Веб-сервис, кстати, крутился на очень слабом железе (эмбеддед), прокачивая через себя и обрабатывая оочень большой поток данных. Все на плюсах.
Никакие JVM и ноды туда бы просто не поместились, потому что на железе было 2 АРМовых мобильных ЦПУ примерно по 0.9 ГГц и 512 Мб памяти. Мегабайт, не Гигабайт! Причем сервер там был чисто чтобы управлять с ГУЯ. Основная задача железки была в молотилке кучи проходящих данных. Редис кстати тоже бы туда не влез.
Так что, Тёма, еще раз: проекты и области совершенно разные. Мир разработки не ограничивается веб-сервисами с перекладыванием данных в БД и обратно.
S>Так что микросервисы на C++ -- это не просто норм, это вполне себе реальная практика. Как раз в духе микросервисного подхода, когда не суть важно, на чем именно пишется конкретный микросервис.
Добавлю: если бы это не пользовалось спросом, то вряд ли были бы генераторы в OpenAPI (Swagger) для плюсовых клиентов (3 штуки) и сервера (2 штуки). Причем за добавление поддержки плюсов топили многие, в том числе Самсунг для использования в своей операционке.
Кстати, печально было, что как раз не было генератора для вашего, so5team, сервера Приходилось вручную лопатить, хотя сваггер-схема была и использовалась со стороны реакта.
Кроме того, есть клиенты и генераторы для плюсов для gRPC. Никто этим не занимался бы, если бы не было нужды. Кстати, и мне лично тоже приходилось ими пользоваться для плюсов.
Здравствуйте, Артём, Вы писали:
S>>В некоторых задачах для GUI не берут ничего кроме подхода IMGUI.
Аё>В первый раз слышу. Спасибо, загуглил.
Т.е. в очередной раз звиздел о том, в чем не разбираешься. Запротоколировано в очередной раз.
Аё>Какое у imgui преимущество перед Angular, React, Flutter, Blazor
Здравствуйте, Артём, Вы писали:
S>>>>Конкретно у so5team -- это различный middleware, вроде упоминавшегося здесь прокси-сервера envoy. Аё>>>Которое лучше переписать на Go.
S>>Попробуй. Обкакаешься, мягко говоря. Аё>Ты просто не умеешь готовить.
Да ладно бы только я.
Ну и вообще ты забываешь тот маленький факт, что в подобных областях практически никто не пишет новые приложения с абсолютного нуля. Как правило, переиспользуется туева хуча уже готового кода (на Си, и на C++). Например, мало кто пишет сам сейчас работу с сокетами, парсинг IP-адресов и пр. Берут Asio или ACE (или libuv). Аналогично и с многими другими вещами. Причем все это уже в течении многих лет вылизано и отлажено так, как тебе и не снилось.
Аё>Пусть aik отпишется. Там вроде linux kernel.
Linux и Free(Net/Open)BSD -- это далеко не весь системный софт.
Аё>Ну другое что-то. Не плюсы.
И что? Название хоть одно вспомнить можешь?
S>>Даже я, очень далекий от игростроя человек, наслышан об активнейшем использовании C/C++ для написания движков, Аё>Ок. Хром наптсан на C++, значит весь веб, весь жаваскрипт- это сиплюсы. Все сиплюсники получается
Нет, получается, что даже в Web-е для C++ все еще есть место, причем очень важное.
S>>Ты в очередной раз звездишь о том, в чем не разбираешься. Аё>мфц стиль маст дай.
Оформление названий -- это дело важное, но далеко не самое важное. Речь шла про качество кода. И ты, в очередной раз, звизданул фигню не будучи ни грамма в теме.
S>>Будь точнее в формулировках, "приложения" -- это что? Можно ли envoy считать приложением? Аё>Application.
Здравствуйте, DiPaolo, Вы писали:
DP>Кстати, печально было, что как раз не было генератора для вашего, so5team, сервера Приходилось вручную лопатить, хотя сваггер-схема была и использовалась со стороны реакта.
Мы делаем эту библиотеку за свои и далеко не всегда для этого есть ресурсы, на какое-то время вообще пришлось ставить работу на паузу. Только в последние несколько месяцев удалось чутка реанимировать проект и хоть что-то туда добавлять.
S>Мы делаем эту библиотеку за свои и далеко не всегда для этого есть ресурсы, на какое-то время вообще пришлось ставить работу на паузу. Только в последние несколько месяцев удалось чутка реанимировать проект и хоть что-то туда добавлять.
Да, я в курсе Читал ваши пояснения на сайте. В том числе (на тот момент) и об окончании поддержки сервера.
Энивей, пользуясь случаем, скажу спасибо А блог ваш я еще лет 10 назад читал задолго до использования сервера
Здравствуйте, DiPaolo, Вы писали:
DP>В том числе (на тот момент) и об окончании поддержки сервера.
Как раз поддержку мы не останавливали, на вопросы отвечали, на issue реагировали. А вот добавить что-то новое не было возможности, т.к. это новое требовало уже перехода на ветку 0.7 и активную работу в течении нескольких месяцев.
Посмотрим как будет дальше. Может когда-нибудь и получится реализовать все, что было в планах. Времена на дворе непредсказуемые, даже сложно предположить какая ситуация будет через год.
Здравствуйте, DiPaolo, Вы писали:
DP>Никакие JVM и ноды туда бы просто не поместились, потому что на железе было 2 АРМовых мобильных ЦПУ примерно по 0.9 ГГц и 512 Мб памяти.
И чо? 512мб. Зажралсь все
DP>Так что, Тёма, еще раз: проекты и области совершенно разные. Мир разработки не ограничивается веб-сервисами с перекладыванием данных в БД и обратно.
Вот смотри, ты сейчас преподнес 512мб рамы и почти 1ггц, как достижение, что туда поделка на сиплюсах влезла. Но это ж embedded, такое на C делается, по-хорошему. Гуй настроек ка водится, на реакт. А чож не на мфс кондовом, да чтоб с инсталлером, а? Или вот состим привел пример "гуи на сиплюсах"- библиотечка с выводом кнопок в opengl.
Ответить на несчастный http запрос от одного клиента на реакте- вот достижение .
S>>Так что микросервисы на C++ -- это не просто норм, это вполне себе реальная практика.
Чувак, ты описал случай из жизни embedded. Это не микросервисы.
Кста, Go вроде умеет компилять под голое железо. Или я гоню? Я почти год назад на Го делал агентика и ьыл впечатлен мощью языка и экосистемы.
DP> Как раз в духе микросервисного подхода, когда не суть важно, на чем именно пишется конкретный микросервис.
Не надо философствовать. Берем типовую задачу — микросервис в AWS. И внезапно, никто на сиплюсах сикросервисы не делает. А на Го- самое то.
DP>Добавлю: если бы это не пользовалось спросом, то вряд ли были бы генераторы в OpenAPI (Swagger) для плюсовых клиентов (3 штуки) и сервера (2 штуки).
Чуваки приколись. даже если swagger использовался 2 раза и то- автором.
DP>Кстати, печально было, что как раз не было генератора для вашего, so5team, сервера
А чо ж ниасили- ни состим, ни вы ниасилили сваггер прикрутить?
DP>Приходилось вручную лопатить,
Мое личное имхо- запилить свой сваггер достаточно реально. Особенно если задолбало вручную лопатить.
Кстати, я оч подозреваю, что в Го есть и http server, и swagger с блекджеком и девицами, причем по памяти оно весьма скромно кушает и при этом не стреляет в ногу
Здравствуйте, Артём, Вы писали:
DP>> Как раз в духе микросервисного подхода, когда не суть важно, на чем именно пишется конкретный микросервис. Аё>Не надо философствовать. Берем типовую задачу — микросервис в AWS. И внезапно, никто на сиплюсах сикросервисы не делает. А на Го- самое то.
Во-первых, для кого она типовая?
Во-вторых, если на C++ микросервисы для AWS никто не пишет, то зачем тогда Амазон выпустил вот это: https://aws.amazon.com/ru/sdk-for-cpp/ ?
(причем ссылку эту тебе здесь уже кидали).
Приходилось вручную лопатить, хотя сваггер-схема была и использовалась со стороны реакта.
А блог ваш я еще лет 10 назад читал задолго до использования сервера 
.
