Boost 1.82

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

отказ от поддержки C++98 в течение двух следующих релизов; минимальным требованием станет компилятор с поддержкой C++11

А в плюсах нумерация в обратную сторону идет чтоли?

Это сокращение от 2к.

А, это годы чтоли? Тогда понятно,спасибо.

А в плюсах нумерация в обратную сторону идет чтоли?

Нет, такое происходит только с их адекватностью.

Так у буста же куча отдельных библиотек?

/usr/lib/x86_64-linux-gnu/libboost_date_time.so
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so
/usr/lib/x86_64-linux-gnu/libboost_graph_parallel.so
/usr/lib/x86_64-linux-gnu/libboost_graph.so
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so
/usr/lib/x86_64-linux-gnu/libboost_math_c99f.so
/usr/lib/x86_64-linux-gnu/libboost_math_c99l.so
/usr/lib/x86_64-linux-gnu/libboost_math_c99.so
/usr/lib/x86_64-linux-gnu/libboost_math_tr1f.so
/usr/lib/x86_64-linux-gnu/libboost_math_tr1l.so
/usr/lib/x86_64-linux-gnu/libboost_math_tr1.so
/usr/lib/x86_64-linux-gnu/libboost_mpi_python310.so
/usr/lib/x86_64-linux-gnu/libboost_mpi.so
/usr/lib/x86_64-linux-gnu/libboost_prg_exec_monitor.so
/usr/lib/x86_64-linux-gnu/libboost_program_options.so
/usr/lib/x86_64-linux-gnu/libboost_python310.so
/usr/lib/x86_64-linux-gnu/libboost_random.so
/usr/lib/x86_64-linux-gnu/libboost_regex.so
/usr/lib/x86_64-linux-gnu/libboost_serialization.so
/usr/lib/x86_64-linux-gnu/libboost_system.so
/usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so
/usr/lib/x86_64-linux-gnu/libboost_wave.so
/usr/lib/x86_64-linux-gnu/libboost_wserialization.so

Самый великий позор C++ и самый лютый говнокод.

Нумерация растёт по модулю 100.

eternal_sorrow:

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

Boost… 🤔 Так и сделано, это и отдельные библиотеки, и уже вносились в разные версии STL.

X512:

Самый великий позор C++ и самый лютый говнокод.

Видимо поэтому они и переехали в стандарт языка. С++ должен быть самым сложным языком программирования, это ведь хорошо, не так ли? 😉

Ну во первых, это мало. В бусте гораздо больше компонентов, чем этот список. Нужно разбить ещё сильнее. А во вторых, эти библиотеки разве поставляются каждая в отдельном пакете?

это и отдельные библиотеки

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

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

Видимо поэтому они и переехали в стандарт языка.

В итоге ~80% процентов стандартной библиотеки C++ представляет из себя мусор. Тем же iostream лучше не пользоваться потому что printf намного быстрее и понятнее.

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

Чем сабж круче Glibc?

Mysql: новая библиотека на основе Asio, клиент MySQL;

Это будет лучшее, чем MySQL++ ?

ООП в стиле Си++, вместо ООП в стиле Си.

Тем же iostream лучше не пользоваться потому что printfнамного быстрее и понятнее.

Если у тебя «тормозит» пользовательский сунь-вынь, ты делаешь что-то не так :) а это вот «быстрее» с т.з. юзера неразличимо, т.к. он медленнее всего. В наколенных микробенчмарках только греется ЧСВ авторов микробенчмарков, которые экономят ничего своими слоптимизациями, да еще выдают свой синдром утенка за «понятнее». Я уж не говорю что их код выглядит как «привет из 90х». И вопросы на собесах про С++20++... а в кодобазе голимое легаси из костылей именно поэтому.

потому что printf намного быстрее и понятнее.

С чего вдруг?

cout для вызывает просто fwrite, printf ещё обязан парсить входящую строку.

Так-то это немного по времени, но cout 100% быстрее printf при одинаковых условиях (для обоих включена буферизация, и cout не синхронизируется с stdio)

Кстати, в С++ есть std::print и std::println. Они просто быстрее printf, и их не нужно настраивать…

С чего вдруг?

Потому что там тонна прослоек, требования синхронизации с stdio.h и странное неотключаеиое поведение сброса буфера при использовании std::endl.

Кстати, в С++ есть std::print и std::println.

(since C++23)

У меня пока нету. Пробовал Clang 15 и GCC 11.

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

В нормальных дистрибутивах с пряморукими мейнтейнерами всё сделано как надо. Если у тебя не так, то выводы надо делать не о бусте, а о мейнтейнерах.

$ sudo dnf install boost-atomic
Последняя проверка окончания срока действия метаданных: 0:05:37 назад, Сб 15 апр 2023 06:41:47.
Зависимости разрешены.
======================================================================
 Пакет             Архитектура Версия               Репозиторий Размер
======================================================================
Установка:
 boost-atomic      x86_64      1.78.0-9.fc37        fedora       20 k

Результат транзакции
======================================================================
Установка  1 Пакет

Объем загрузки: 20 k
Объем изменений: 21 k
Продолжить? [д/Н]: n

странное неотключаеиое поведение сброса буфера при использовании std::endl.

Я вообще не проверял, но в чём проблема просто сделать << "\n" вместо << std::endl, если тебе не нужен сброс буфера? Вот тебе и отключение.

Ну и в целом, если тебе, как мне например, не нравится iostream, то пользуйся fmtlib/std::format, он намного лучше printf и т.п. уже хотя бы тем, что проверяет строки в компайл-тайме и позволяет форматировать сложные типы. Ну и производительность у него, естественно, выше.

Потому что там тонна прослоек, требования синхронизации с stdio.h и странное неотключаеиое поведение сброса буфера при использовании std::endl.

Я уверен что /n и буферизирование

vector<char> buf(65536);
cout.rdbuf()->pubsetbuf(buf.data(), buf.size());

решат все твои проблемы с cout.

потому что printf намного быстрее и понятнее.

Да ну бред же. «Какие ваши доказательства»?

https://stackoverflow.com/questions/18688763/why-is-istream-ostream-slow

в чём проблема просто сделать << «\n»

Возможно в том что << '\n' существенно эффективнее. Но вы наверное немножко другое имели в виду.

Там сравнивают iostreams и fwrite(). Не надо так. Тягаться нужно с printf() and family.

Компилятор может автоматически менять printf на puts или fwrite когда это возможно.

Компилятор может автоматически менять printf на puts или fwrite когда это возможно.

Примеры в студию. И мне бы хотелось услышать развитие темы «когда это возможно».

#include <stdio.h>

int main()
{
    printf("This is a test.\n");
    return 0;
}

clang 16 riscv64:

main:                                   # @main
        addi    sp, sp, -16
        sd      ra, 8(sp)                       # 8-byte Folded Spill
.Lpcrel_hi0:
        auipc   a0, %pcrel_hi(.Lstr)
        addi    a0, a0, %pcrel_lo(.Lpcrel_hi0)
        call    puts@plt
        li      a0, 0
        ld      ra, 8(sp)                       # 8-byte Folded Reload
        addi    sp, sp, 16
        ret
.Lstr:
        .asciz  "This is a test."

https://stackoverflow.com/questions/18688763/why-is-istream-ostream-slow

по твоей ссылке последний ответ на баг репорт в Visual C++ от 2011 года где Стефан провёл тесты iostream и в он оказался быстрее printf а баг закрыт «Closed as By Design»

Вот скопирую ссылку из stackoverflow: https://web.archive.org/web/20170329163751/https://connect.microsoft.com/VisualStudio/feedback/details/642876/std-wcout-is-ten-times-slower-than-wprintf-performance-bug-in-c-library

Ну там прямым текстом сказано же: boost - «booze», бухалово. Как думаешь, можно написать хороший код под градусом?

Там string literal, слишком примитивно. Распечатайте int какой нибудь, или double.

А вот интересно, а может ли кто объяснить мне зачем? Трава стала зеленей? В 11-й волшебные кнопки появились, без которых жить неможно? Для чего это всё? Лишь бы искусственно «гнать лошадей?»

String literal без параметров на практике встречается очень часто.

Не любил буст за переусложненные и многословные интерфейсы. Но теперь, открываешь cppreference, а там почти все новые стандартные функции и классы такие же. 😕

В серьезных проектах за использование boost уволить могут.

В качестве теста идей перед включением в std это норм, но в качестве использования в продакшене не пригодно.

В серьезных проектах за использование boost уволить могут.

Хорошо что Apple и Google занимаются несерьёзными проектами.

Лол, они не то что используют boost. Они нанимают людей чтобы те становились мейнтейнерами boost

Хорошо что Apple и Google занимаются несерьёзными проектами.

И где там буст? В каком-нибудь протухшем legacy, да еще помечен как deprecated, чтобы кто-нибудь в новых проектах не стал вдруг использовать?

Они нанимают людей чтобы те становились мейнтейнерами boost

Откуда этот бред?

Всё лучше, чем сишка

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

В серьезных проектах за использование boost уволить могут.

В качестве теста идей перед включением в std это норм, но в качестве использования в продакшене не пригодно.

Признайтесь - кто Вы? Нация должна знать своих героев…

ИМХО шаблоны в C++ от неумения разработать компилятор, который бы поддерживал адекватное метапрограммирование.

В качестве теста идей перед включением в std это норм, но в качестве использования в продакшене не пригодно.

ПыСы. Есть вещи в std:: за которые я готов «яйца оторвать». std::minmax() например. И это одно из немногого что выстрелило на днях. Пожалуйста, не рассказывайте о проде если вы понятия не имеете о чём речь…

Ничего не имею против std.
Для меня std, как одна из библиотек, имеющая богатый API.

Но и не использую, так как разрабатываю API для работы с метаданными.

Даже более того, использую лишь свое API для работы c строками.

Пока все ok!

Почему так?

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

И.т.д., и.т.п.

Пост к тому, что C/C++ прекрасно подходят для системного программирования.

аналогично. как пример - такой милый сердцу и клаcсический ringbuffer, вот он в бусте

https://www.boost.org/doc/libs/1_82_0/doc/html/boost/circular_buffer.html

только заголовков имеет больше, чем его обычная реализация, причем 80 процентов описанных фич вообще не нужны.

нормальные посоны запрещают копирование, присваивания и мувы таких структурных классов, просто потому, что их копирование и присваивание - это явная ошибка архитектуры.

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

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

то есть, если ты ищешь реально эффективную реализацию тут… ее проще написать ручками, чем брать этот пугающий шаблон.

Есть вещи в std:: за которые я готов «яйца оторвать»

Конечно есть. Тот же std::chrono, который, кстати, из буста притащили.

Готов выслушать ваши предметные претензии к boost::circular_buffer.

Более того: с господином eao197 мы до сих пор ждём ссылки на ваши «шедевры».

Готов выслушать ваши предметные претензии к boost::circular_buffer.

а к вам никто и не обращался.

а к вам никто и не обращался.

В вашем случае - кишка тонка.

Но это не отменяет факта что мы до сих пор ждём… И да - возвращаясь к предмету разговора - примеры будут? Или мы только «потрепаться»?