LINUX.ORG.RU

Boost 1.82

 ,


2

6

Вышла новая версия Boost, набора кроссплатформенных библиотек C++. Некоторые крупные изменения:

  • более 20 библиотек запланировали отказ от поддержки C++98 в течение двух следующих релизов; минимальным требованием станет компилятор с поддержкой C++11 (например, gcc 4.8 и выше);
  • некоторые библиотеки (Math, Multiprecision) повышают требования к стандарту до C++14 (gcc 5, clang 5);
  • Mysql: новая библиотека на основе Asio, клиент MySQL;
  • Unordered: unordered_node_map, unordered_node_set - новые контейнеры на основе открытой адресации.

А также множество улучшений и исправлений в Core, Asio, Filesystem, JSON, Math, URL и других библиотеках.

>>> Подробности

★★★★

Проверено: maxcom ()
Ответ на: комментарий от raspopov

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

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

X512 ★★★★★
()
Ответ на: комментарий от X512

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

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

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 4)
Ответ на: комментарий от X512

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

С чего вдруг?

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

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

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

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от fsb4000

С чего вдруг?

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

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

(since C++23)

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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

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

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

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

Ivan_qrt ★★★★★
()
Ответ на: комментарий от X512

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

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

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

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

fsb4000 ★★★★★
()
Ответ на: комментарий от Ivan_qrt

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

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

bugfixer ★★★★★
()
Ответ на: комментарий от X512

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

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

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer
#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."
X512 ★★★★★
()
Ответ на: комментарий от X512

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

fsb4000 ★★★★★
()
Ответ на: комментарий от bugfixer

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

X512 ★★★★★
()
Ответ на: комментарий от fsb4000

С чего вдруг?

Скорее субъективщина, но подход с форматными строками (правда, не printf-like, а fmt-like) выглядит лучше. К тому же он ещё и более расширяем, потому что в iostreams наличие стейтов для форматирования вывода (типа std::hex, std::fixed) захардкожено, а в fmt-like можно добавить какие угодно свои стейты.

А если говорить про быстродействие, то да, незначительно быстрее, есть выключить всё ненужное.

f1u77y ★★★★
()
Ответ на: комментарий от X512

Ну да, это новая фича, но уже с С++20 можно написать однострочную обёртку над std::format_to, если хочется

f1u77y ★★★★
()
Ответ на: комментарий от f1u77y

Вон в софте в файлах переводов так и пишут Hello %s, you have %i credits. Очень удобно

А ещё можно прямо в бинарнике программы строки править. Сразу всё понятно. А с iostream такого удобства нету.

Стейты iostream вообще просто ненавижу. Уж лучше свой велосипед

bga_ ★★★★
()
Последнее исправление: bga_ (всего исправлений: 2)
Ответ на: комментарий от bga_

У меня так:

  pchResult =
   Metastrcat(
    pchResult,
    "Hello ",
    pchString01,
    ", you have ",
    pchString02,
    " credits"
    1
   );

Работает быстро (и выделение памяти происходит лишь один раз)!

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 1)
Ответ на: комментарий от bga_

Это не template.

template<Args…>? Можно формировать из чего угодно?

Например так:

 *(char **) pAddItem = 
  Metastrcat( 
   *(char **) pAddItem ,
   argv[ i ] + 2 ,
   1
  );

Как угодно!

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 1)
Ответ на: комментарий от bga_

Фича Metastrcat() в том, что не нужно использовать никакой форматной строки.
Не нужно ее использовать там, где и без нее можно обойтись без проблем.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 1)
Ответ на: комментарий от Forum0888

Моё чтобы в юзерские шаблоны свои данные подставлять. И например медленно писать в UART. При этом жрать минимум ОЗУ

bga_ ★★★★
()
Последнее исправление: bga_ (всего исправлений: 1)
Ответ на: комментарий от bga_
// -------------------------------------------------------
// --- Добавляет строки к исходной
//
CHAR  * Metastrcat(
 CHAR  *pSource,
 ...
) {
/*

 pSource                Исходная строка

*/

  INT    iVp01           = 0;                              //        

  CHAR   *pTemp          = nullptr;                        // Значение аргумента
  INT    cntpTemp        = NULL;                           // Длина значения аргумента функции

  CHAR   *pResString     = nullptr;                        // Результирующая строка
  INT    cntResString    = NULL;                           // Длина результирующей строки

  CHAR   *pCurpResString = nullptr;                        // Адрес текущей позиции в результирующей строке

  CHAR   **pArgument     = nullptr;                        // Адрес значения аргумента функции

  INT    cntpSource      =                                 // Длина pSource
   Metastrlen(
    pSource
   );

// Рассчет количества символов во всех аргументах функции
//
  CHAR  *p = (CHAR *) &pSource;

  while ( 1 ) {

   pTemp = *(CHAR **) p;

   if  ( pTemp == (CHAR *) 1 )
    break;

   cntResString +=                                         // Длина результирующей строки
    Metastrlen(
     pTemp
    );
   
   p = (CHAR *) ( (BYTE *) p + 4 );                        // Адресуем следующий аргумент

  }                                                        // while ( 1 ) {

// Выделяем память для результирующей строки
//

  pResString = (CHAR *) malloc( ( cntResString + 1 ) * sizeof( CHAR ) );

  *(CHAR *) ( (CHAR *) pResString + cntResString ) =       // Сформировали строку
   (CHAR) 0;

// Формируем текст результирующей строки
//
  pCurpResString =                                         // Адрес текущей позиции в результирующей строке
   (CHAR *) pResString;

// Получаем знчения аргументов функции и помещаем их в результирующую строку
//
  p = (CHAR *) &pSource;

  while ( 1 ) {

   pTemp = *(CHAR **) p;

   if  ( pTemp == (CHAR *) 1 )
    break;

   cntpTemp =                                              // Длина значения аргумент
    Metastrlen(
     pTemp
    );

// Копируем значение аргумента
//
   memcpy(
    pCurpResString,                                        // Адрес результирующей строки
    pTemp,                                                 // Адрес исходной строки
    cntpTemp * sizeof( CHAR )                              // Количество копируемых байт
   );

   pCurpResString  +=                                      // Адрес текущей позиции в результирующей строке
    cntpTemp;
   
   p = (CHAR *) ( (BYTE *) p + 4 );                        // Адресуем следующий аргумент

  }                                                        // while ( 1 ) {

  *( pResString + cntResString ) = '\0';                   // Сформировали строку

  free(                                                    // Освободили память память, содержащюю данные до добавления строки
   pSource
  ); 

  return  pResString;                                      // 

}
Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 1)
Ответ на: комментарий от bga_

%s, %i

Это устаревший и к тому же error-prone метод. Особенно если в коде идут типы с известным размером (вида uint64_t). printf("a = %" PRIu64 "; b = %" PRIuFAST32\n", a, b) выглядит не лучше iostreams.

f1u77y ★★★★
()
Ответ на: комментарий от f1u77y

Потому что нужен string interpolation как в нормальных яп. А не изобретение одинаково кривых велосипедов

bga_ ★★★★
()
Ответ на: комментарий от bga_

Это все для compil-time.

Разрабатываемый API для работы с метаданными имеет много большую функциональность и используется в run-time.

Forum0888
()
Ответ на: комментарий от bugfixer

«Какие ваши доказательства»?

C++ iostream vs. C stdio performance/overhead

Does the C++ standard mandate poor performance for iostreams, or am I just dealing with a poor implementation?

и дальше по списку.

Форматирование было ужасно медленным. boost::format ситуацию только ухудшал, ЕМНИП.

Но с появлением fmt жизнь стала сильно лучше. Собственно, fmt позволяет сделать всё по-человечьи, python-like форматирование, без необходимости очковать за битность передаваемых данных, и всё это с приличной производительностью.

AlexM ★★★★★
()
Последнее исправление: AlexM (всего исправлений: 1)
Ответ на: комментарий от bugfixer

Посмотрите. Будет здорово, если опубликуете где-то.

Я лет десять назад озадачивался вопросом, WTF is going on???

По итогу нашёл для себя fmt (в девичестве c++format), перевёл весь наш немаленький проект на него (а в логгировании для это нас это актуально, т.к. мы высираем тонны логов в level=DEBUG, logrotate не справляется :-)), и ни разу не пожалел, т.к. получил инструмент, которым даже джуниор не может развалить или существенно замедлить программу, логгируя, что же именно он достал из битового потока.

AlexM ★★★★★
()
Ответ на: комментарий от f1u77y

Ну, если библиотека форматирования нормальная, то она на «%d» позволяет не замечать разницы между i16, i32, i64 и i128.

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

Если она нормальная, то там в принципе нет разницы между обозначениями формата для всех типов в дефолтном представлении

f1u77y ★★★★
()
Ответ на: комментарий от f1u77y

Ну, нет, конечно. Иногда хочется странного типа %04d или %.2f и прочих выравниваний.

А вот там, где подобное не нужно, - там действительно {}

AlexM ★★★★★
()
Последнее исправление: AlexM (всего исправлений: 1)
Ответ на: комментарий от AlexM

Форматирование было ужасно медленным

Никогда iostream не был медленным.

Что уж говорить про обычные задачи, он используется даже в competetive programming, где есть специально подобранные задачи на вывод.

Скопирую свой ответ 2021 года.

If you need speed, you need to enable buffering. And with buffering iostream is much faster than fmt::print (~3 times faster)

constexpr std::size_t size = 1024 * 8;
char buffer[size];
std::cout.rdbuf()->pubsetbuf(buffer, size);
std::ios::sync_with_stdio(false);
fsb4000 ★★★★★
()
Ответ на: комментарий от fsb4000

Ну-у-у, ок.

Мои давнишние замеры давали другие результаты. Да и форматирование значений в стриме через запихивание флагов в тот же стрим — это какой-то треш.

Но допускаю, что на вкус все фломастеры разные.

AlexM ★★★★★
()
Последнее исправление: AlexM (всего исправлений: 1)
Ответ на: комментарий от AlexM

Вообщем то вы правы.

Обычно у меня в исходном коде строчкой выше Metastrcat()
находится комментарий, содержащий форматную строку и проблема «не читабельности» устраняется.

Суть постов, связанных с Metastrcat() была в том, что многие
программисты ведут разработку как «зомби» и не задумываются о том, что их алгоритм ресурсоемок.

Впрочем таковые времена наступили давно.

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

На счет оценки harbour ваше суждение просто «ни о чем», так как о core этого проекта вы ничего не знаете.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 6)
Ответ на: комментарий от Forum0888

Данный тред — про релиз библиотеки (набора библиотек) Boost для C++.

Рассказ о судьбах мира, и «люди, я принёс вам сердце» лучше приберечь для другого треда.

AlexM ★★★★★
()
Ответ на: комментарий от Reset

Насколько я понимаю, в стандарт ушла как раз fmt, так что, да, есть поддержка и {}, и %.

AlexM ★★★★★
()
Ответ на: комментарий от Reset

Хм, сканф типонебезопасен.

Вообще, Boost.Spirit генерит хорошие по качеству парсеры. Но сейчас я бы использовал ANTLR.

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

Хм, сканф типонебезопасен.

Да

Вообще, Boost.Spirit генерит хорошие по качеству парсеры. Но сейчас я бы использовал ANTLR.

Ога, особенно это годится для наколенных поделий и одноразового кода типа кода для соревнований :)

Reset ★★★★★
()
Ответ на: комментарий от AlexM

Вообще, Boost.Spirit генерит хорошие по качеству парсеры. Но сейчас я бы использовал ANTLR.

Если речь идёт о более серьёзных вещах, чем разбор HTML/JSON/INI (для которых и так есть готовые тулзы), то уж лучше вручную костылять на 99-ой Сишечке, чем потом страдая пытаться избавиться от всех недостатков готового комбайна, тем более написанного на Джаве.

Dr64h ★★★
()
Ответ на: комментарий от Reset

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

AlexM ★★★★★
()
Последнее исправление: AlexM (всего исправлений: 1)
Ответ на: комментарий от AlexM

fmt же, говорят, в стандарт затащили (ну, точнее, сделали стандарт на основе fmt).

Ну да, это как раз std::format. Только вот проблема, что единственная доступная для линукса сейчас реализация std::format - это всё тот же fmtlib, а ни в libstdc++, ни в libc++ своё ещё не завезли. В msvc вроде что-то сделали, но я не проверял.

Так что я пока по-прежнему fmtlib тащу и не парюсь.

Ivan_qrt ★★★★★
()
Ответ на: комментарий от dataman

Собственно, главной моей претензией к Спириту является (являлся) степенной рост сложности инстанциируемого кода при росте сложности грамматики. Работает, спору нет, быстро, но компиляется века́ми.

У PEGTL подход /внешне схожий/. И как оно, не ставит канпелятор колом?

AlexM ★★★★★
()
Ответ на: комментарий от dataman

Чо-т я боюсь представить себе, как будет выглядеть сколько-нибудь сложная грамматика при таком подходе.

AlexM ★★★★★
()
Ответ на: комментарий от dataman

Дополню, что обе используют алгоритм Ryu, а не Dragonbox, как в fmtlib.

dataman ★★★★★
()
Ответ на: комментарий от AlexM

Вообще, Boost.Spirit генерит хорошие по качеству парсеры.

Которые медленные не только по скорости компиляции, но и даже по выполнению?

O02eg ★★★★★
()
Ответ на: комментарий от AlexM

Да сам пока экспериментирую. :)

Мне в lexy нравятся парсеры различных классов и свойств юникодных символов, тогда как в PEGTL для этого используется ICU.

dataman ★★★★★
()
Ответ на: комментарий от AlexM

Вы, видимо, не в теме про генераторы парсеров.

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

Dr64h ★★★
()
Ответ на: комментарий от Dr64h

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

AlexM ★★★★★
()
Ответ на: комментарий от O02eg

На моих тестах (пятнадцатилетней давности) работало как из пушки.

Из опубликованного прямо сейчас могу вспомнить только статью Алекса Отта

Вообще, конечно, от грамматики, и того, как она описана, зависит многое. Так что, YMMV

AlexM ★★★★★
()
Последнее исправление: AlexM (всего исправлений: 1)
Ответ на: комментарий от AlexM

компиляется века́ми

Вторая версия поди? X3 сильно быстрее, за годы может справиться.

Правда, оно из experimental никак не выходит, и видимо уже не выйдет.

unsigned ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.