А мой опыт подсказывает обратное? Будем меряться, у кого опыт длиннее? Только какой в этом смысл?

Где ebuild-ы для Gentoo ?

здесь не смотрели ?

http://portage.perestoroniny.ru/dev-util/boost-build/

http://portage.perestoroniny.ru/dev-libs/boost/

или хотя бы здесь ?

https://github.com/geki-yaba/gekis-playground.git

Beast — реализация протоколов HTTP/1 и WebSocket поверх Asio;

Редкостная параша, нирикаминдую.

Пробовали, совсем плохо? А, может, подскажете, что неплохо для достижения цели получения встроенного HTTP-сервера с вебсокетами? Сейчас используем велосипед поверх libevent, но, может, есть более бо́льные способы (не путать с больны́ми :) ?

Медленно работает - можно пример? И пример быстрого аналога.

Boost.Format: https://github.com/fmtlib/fmt#benchmarks Boost.Log: https://kjellkod.wordpress.com/2015/06/30/the-worlds-fastest-logger-vs-g3log/

ну, и этим список не исчерпывается, есть ещё Boost.Function & Co.

Тот же fmt достаточно легко таскать с собой, boost.format отдельно только вытаскивать устанешь - он тянет за собой кучу всего из boost. При этом не понятно, чем последний лучше.

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

Быстрее его уже некуда. Есть бенчмарки с другим результатом?

Я знаю. Поэтому fmt наш выбор :)

Первое, там был вопрос про аналоги на Си. Тот же fmt на крестах писан.

Второе - я и не говорил, что буст самая быстрая либа в мире.

Первое, там был вопрос про аналоги на Си. Тот же fmt на крестах писан.

Boost.Format сливает всем. Это, на самом деле, постараться нужно было.

Второе - я и не говорил, что буст самая быстрая либа в мире.

Вы удивились утверждению, что она тормозная, и попросили подтверждений. Быть в семь с половиной раз тормознее printf'а — это прямо нешуточная ачивка.

Пробовали, совсем плохо?

Это первый релиз. Если и пробовали - то да, совсем плохо, но не с библиотекой.

Beast — реализация протоколов HTTP/1 и WebSocket поверх Asio

А WebDAV поверх всего этого ещё никто не запилил?

Быстрее его уже некуда

А, ну если конечно речь не идет про ordered_хрень. Как пул одиночных объектов он идеален, остальное - имхо, не его дело.

Чем замените в Си RAII

Обычно его заменяют, например, реализациями с goto переводящим в конец функции, где и происходит очистка, или нестандартным атрибутом функции cleanup (есть в gcc и clang). Соответствующие примеры в русско- и англоязычной вики.

Также, если я правильно понял, пример можно увидеть в проекте Darktable, где применяется goto error и очистка в блоке, где расположена метка error:.

goto error

Костыли.

приведи решение лучше используя стандартные средства, а пока все пользуются этим

Ну, как, они же не из воздуха образуются, библиотеки-то.

И перед релизом, НЯЗ с процессом в бусте, есть довольно долгое обсасывание кода, принятых технических решений и прочего.

Некоторые вон, годами в отстойнике живут, «доходят до кондиции». Так что, познакомиться с большинством библиотек можно заранее.

бампануть сам могу, так неинтересно

Пробовали, совсем плохо?

Пробовал, но в роли HTTP-клиента. Очень не понравилось. libcurl намного лаконичней.

может, подскажете, что неплохо для достижения цели получения встроенного HTTP-сервера с вебсокетами? Сейчас используем велосипед поверх libevent, но, может, есть более бо́льные способы (не путать с больны́ми :)

Вебсокетов делать не приходилось, но для HTTP точно так же свой велосипед (правда поверх libev) с готовым парсером (picohttpparser в моем случае).

Всё так, но афаик Beast только родился и сделан скорее как дешевая альтернатива Boost.Http, которую никак не закончат (или уже не пытаются?). Хотя, стоит покопаться в истории.

Всё так, но афаик Beast только родился

Boost.Beast широкой общественности известен, как минимум, с осени 2016-го года, когда Винни Фалько, автор Beast-а, сделал короткий доклад на CppCon2016: https://www.youtube.com/watch?v=uJZgRcvPFwI

До лета 2017-го Beast довольно активно развивался. А когда в середине лета 2017-го его официально приняли в Boost, Beast стал допиливаться еще активнее. В Boost-1.65 включить Beast не успели, вот только в 1.66 завезли.

Так что в определенных кругах о Beast-е известно довольно давно.

Ок, спасибо. Я увидел первые анонсы в конце весны.

А, может, подскажете, что неплохо для достижения цели получения встроенного HTTP-сервера с вебсокетами?

Если нужны только WebSocket-ы, то есть uWebSockets, есть WebSockets++. Если же нужен и HTTP, и WebSockets, то есть CROW, есть RESTinio.

используя стандартные средства

С++, RAII, Exception.

Да, и при всём при этом в вашем говнобусте есть зачастую далеко не всё необходимое, так что велосипедостроение - актуально.

Если спросишь чего нет - например: цилиндрических функций от комплексного аргумента (казалось бы чего проще, а нет, не завезли). Проверки целостности кадра при приёме по сериальному порту - тоже нет, зато в его (сериального порта) реализации - шаблон на шаблоне, шаблоном погоняет.

ЗЫ. Другой анонимус.

Речь о языке C, если ты забыл.

Вопрос не в том чего нет

Там много чего нет и никогда не будет. Вопрос в том зачем писать свои кривые велосипеды когда есть готовая имплементация в бусте. Обычно это явный признак профнепригодности.

а почему нужно выбрать именно Boost, а не Qt в тех случаях, когда нужные имплементации есть и там и там?

Спасибо за ссылки. Интересно было почитать бенчмарки.

iostreams медленный, потому что у него относительно много фич: поддержка локалей (ставить зарятую или точку), ширины полей, выравнивания и т.д. (наверное удобно для написания консольных утилит). Причем все это начиналось в далекие 90е (или раньше) и пролезло в стандарт, поэтому так и живёт.

Но iostreams не умеют работать с шаблонами (aka printf), поэтому не подходят для вывода локализованных строк (12 марта - March, 12), эту проблему и решал boost.format (подробнее в каждой библиотеке есть rationale). Причем он сам опирается на iostreams, поэтому быть быстрее не может.

Вообще boost - это же не одна библиотека, а набор. И «тянет пол буста» - это обычно базовые либы или для поддержки кросс-платформенности или для метапрограммирования, что все равно не влияет на размер бинаря.

Ещё ж надо смотреть в исторической перспективе - буст появился когда не было ни гитхаба, ни что-то еще. Да и пока не развились нормальные пакетные менеджеры для native (типа conan), проще взять один boost, чем как-то раскладывать кучу мелких либов (в коммерческой разработке).

Да, спасибо за разъяснение.

Я, хоть уже почти и не программист совсем, ещё помню немного, как оно устроено внутри.

Ну, если (осмотрительно) взять требуемую бустовую библиотеку — заметно больше шансов, что в какой-то момент можно будет переехать на std:: с минимальными переделками. Qt — это совершенно свой набор велосипедов, к LibStdC++ практически не имеющий отношения.

Безоглядный выбор буста — это как раз признак профнепригодности. Точнее — наивности и неопытности. Примеры — выше по треду.

Спасибо.

Я, хоть уже почти и не программист совсем

Безоглядный выбор буста — это как раз признак профнепригодности

А когда-то...

В языке C все это тоже велосипедится, естественно. Да, больно, да, трудно.

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

Для чистого C есть, например, https://github.com/psevon/exceptions-and-raii-in-c/ (сам не использовал).

Я просто открыл первый проект, который вспомнил, что он написан на чистом C, и ткнул первый попавшийся файл и там это было в таком виде, о котором читал раньше.

Сам придумал?

Сам посмеялся? Тебе талдычат про велосипедостроение на ровном месте, а ты про мифический «безоглядный выбор буста», ну, сражайся дальше с соломенным человеком.

Хех :-)

Ту грамматику я потом докручивал ещё несколько месяцев, просирая сроки и навлекая на себя молнии Зевса своего параллелзового начальника. Результат компилировался минут 10, ей-же-ей, дольше, чем весь остальной проект. Сейчас, конечно, я взял бы Antlr или ещё какой аналогичный генератор, и не выеживался бы. Но «нужно было попробовать» ;)

Однако, в январе 2017-го года, на пьянке к Дню рождения своего бывшего начальника, 8 лет спустя моего увольнения из ||, граждане из параллелзового саппорта мне жали лапу за ту подсистему. Признаться, был удивлен-польщен-смущен. Более всего, удивлен, конечно.

Своей головы нет?

или приказ нужОн? В большинстве случаев boost предпочтительней, потому что 1) это стандартный C++ и playground для будущих библиотек в стандарте. 2) boost это библиотека, Qt это фреймворк, со всеми вытекающими.

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

Какие плюсы

Какое может быть вдумчивое разбирательство? Там причина ровно одна - NIH синдром. Ладно сейчас, когда в std перешло часть буста, но в C++98 что такие велосипедостроители делали? Писали свои смартпоинтеры? писали свою абстракцию над файловой системой? писали свои велосипеды по работе с датой/временем? писали свой bind/function? писали свои треды? писали свои шейрд мютексы? писали свои фьючеры? И это я только самые стандартные библиотеки называл, которые есть практически в любом проекте на C++. Да и даже сейчас, даже если доступен C++17, какой наркоман будет писать свой boost.asio? boost.format? boost.algorithm? boost.dll? boost.interprocess? boost.lockfree? boost.serialization? boost.uuid? Тут скорее вопрос, почему ниасиляторы так боятся буста. Ответ один - тотальный NIH-синдром и неумение читать чужой код.

Представьте себе, и в 2017, когда Илон Маск уже почти отправил человечество на Марс в вакуумном поезде когда есть std::function, лямбды и всякие остальные средства, люди продолжают пилить «невозможно быстрые делегаты» и тому подобное. Просто потому, что им, представьте на минуточку, важно, чтобы код работал быстрее, чем то, что предлагает стандарт и буст. И, что характерно, пишут про это статьи, выступают на CppCon-ах и прочих публичных местах.

Про сравнение производительности Boost.Format с fmt я уже написал выше. Замечу, fmt, в девичестве cppformat, начиналась именно как «велосипед» и nih-синдром, Boost.Format'у к тому времени было уже почти 10 лет как, наличествовала ещё пачка других библиотек для этой же цели.

Мое утверждение следующее: в составе буста много всяких библиотек. Эти библиотеки пишутся разными людьми и отличаются по качеству задумки, по качеству проектирования и по качеству реализации. Включение в состав основного Буста не гарантирует ни один из вышеперечисленных параметров, но позволяет надеяться, что когда-нибудь, может быть, часть библиотек из этого набора будет принята после допиливания* в стандарт. И потом, ещё через некоторое время, можно будет надеяться, что оно появится в более-менее распространенных компиляторах «иcкаропки». Но это не точно.

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

Использование чужого «велосипеда» чревато тем, что автор потеряет интерес к детищу, и проект не будет подхвачен кем-то ещё.

* я помню, какую тонну негативных эмоций у меня вызвала какая-то из первых реализаций Boost.Filesystem. «Сраные лунатики, не догадывающиеся, что работа с файловой системой уже реализована на достойном уровне в десятке мест, и все, что нужно, — это перенести наработки на почву C++». В v3, кстати, уже почти все, что нужно, было допилено.

У меня коллега глядя на мой кусок кода как тоже спросил, а чего ты не используешь функци из boost для отрезания куска строки до пробела. На мой вопрос зачем мне его тащить в код класса на 200 строк, если мой велосипед для этого занимает 2 строчки и нужен от силы 2 раза, он ответил разве что «ну boost же всё равно уже установлен», забыв добавить, что он у него установлен, а не у меня.

К тому моменту, когда что-то примут в очередной раз из boost в стандарт, там несколько раз могут успеть что-нибудь поменять, а код, где он мог бы пригодится уже несколько раз либо перепишут, либо забудут о нём. Проверьть каждый раз не поломали ли они в новой версии что-нибудь не у всех есть желание, как и желание держать несколько версий boost.

какой наркоман будет писать свой boost.asio? boost.format? boost.algorithm? boost.dll? boost.interprocess? boost.lockfree? boost.serialization? boost.uuid?

Как заметили выше, это будет делать «наркоман», который недоволен реализацией в boost и может написать библиотеку лучше.

Ответ в том же: Есть в бюсте обертка для последовательного порта ? - есть. Нужно ли писать свой лисапет - да нужно, ибо то, что в бюсте не умеет в контроль ошибок фрейма, не умеет корректно работать с различными драйверами VCP. То что там совершенно неуместно напичкано шаблонами ещё как-то можно было бы стерпеть, но вместе с другими условиями - тоже причина.

Опять же есть в бюсте потоки ? Есть. Давай вылезь с этими потоками напр. в сановский компилятор под солярку, увидишь где вся твоя кроссплатформенность.

Есть в бюсте гиперболические функции ? Есть. Давай попробуй чо-нить с ними собрать под Cell SPU. Вообще в бюсте много чё есть, только по факту оно малопригодно где-то за пределами Винды-Слюникса на x86, да и то с очень ограниченным набором компиляторов (gcc и msvc).

Да, качеством реализации они отличаются - в основном говнокод на говнокоде.

Такое: #ifdef SOME_COMPILER SOME_HACK(); #endif

в кроссплатформенной библиотеке общего назначения вообще неприемлемо.

Сам придумал? Расскажи, как иначе ты обеспечишь сборку на разных странных SOME_COMPILER.

Чем замените в Си RAII

слишком толсто. ну или некрасиво. не удаляйтесь от темы «boost - мешает»

получения встроенного HTTP-сервера с вебсокетами

https://libwebsockets.org/

https://github.com/uNetworking/uWebSockets

а вот это не работает штоль?

Если _GNUC_, _MSC_VER, __BORLANDC - странные SOME_COMPILERы, то тогда да, никак. Правда, совсем странные компилеры типа Sun/Oracle, Green Hills или Keil не собирают буст даже и с такими уговорами.

Спасибо за ответ.

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