прежде чем дрйдет до обработчика ифа

у меня какая проблема. OpenSsl крешит, при том из за того, видимо, что ossl создает кой то синглтон, который уничтожается, но при этом курл который в другом детаченом потоке

обращается к нему

у меня какая проблема. OpenSsl крешит, при том из за того, видимо, что ossl создает кой то синглтон, который уничтожается, но при этом курл который в другом детаченом потоке

Хм. Похоже здесь в проекте все решилось строчкой curl_easy_setopt(m_curl, CURLOPT_SSL_VERIFYPEER, connConfig.sslVerify ? 1 : 0);

так она вроде, отключку делает чего то ж?

Хм. Похоже здесь в проекте все решилось строчкой curl_easy_setopt(m_curl, CURLOPT_SSL_VERIFYPEER, connConfig.sslVerify ? 1 : 0);

А у вас такая же была проблема?

крэшей не было точно

Curl multi + perform конечно притормозит выполнение, пока все таски не завершатся. Иначе делается через события на сокетах: через curl_multi_fdset - extracts file descriptors from multi handle, этот fdset скармливаешь в select()/WaitForMultipleObjects, по выходу вызываешь соответствующие curl_multi_socket_action. Тогда главный поток остается под твоим контролем. Я пробовал в одном своем pet-project, сейчас деталей не помню.

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

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

Если работу с curl сделать в отдельном потоке, то основной поток не будет тормозиться.

Там в Boost обсуждают как стать более привлекательными для пользователей. У кого какие идеи/пожелания?

Закопать?...

container, dll, spirit, intrusive, hana, program_options, stacktrace, local_ptr, asio... и некоторые другие библиотеки всё ещё полезны

Там в Boost обсуждают как стать более привлекательными для пользователей. У кого какие идеи/пожелания?

документацию бы как в Qt, но боюсь это нереально

Там в Boost обсуждают как стать более привлекательными для пользователей. У кого какие идеи/пожелания?

Поработать над документацией. Поработать над пакетированием. Поправить баги Завезти cmake

документацию бы как в Qt, но боюсь это нереально

А как в Qt? В чём принципиальное отличие?

Поработать над документацией. Поработать над пакетированием. Поправить баги Завезти cmake

второе и четвёртое сейчас активно пилят третья пилят всегда

А как в Qt? В чём принципиальное отличие?

Я могу пояснить. В qt к примеру намного больше примеров. И каждая сущность либы лучше описана

А как в Qt? В чём принципиальное отличие?

Много примеров, описываются подводные камни частые, описана более простым языком (легче понимать), общий вид приятнее (сам хтмль приятно кликать и смотреть, по хипстерски выглядит), очень много кликабельного (например, функция принимает какой-то тип из Qt, прям в обьявлении функции можно по нему сразу кликнуть и пойти посмотреть что к чему). Как частный пример - если я захочу понять, как использовать какую-то бустовую либу я никогда не пойду на саму документацию буста. Я пойду искать примеры или статьи на стэковерфлоу/хабре/что еще гугл выдаст, потому что мне сложно даже понять с какой стороны подступиться к документации буста.

второе и четвёртое сейчас активно пилят третья пилят всегда

А есть какие-то приблизительные даты релиза с поддержкой CMake?

Там в Boost обсуждают как стать более привлекательными для пользователей. У кого какие идеи/пожелания?

БЛИН, АНТОН! Это очень просто. ПРОСТАЯ ДОКУМЕНТАЦИЯ!

Там в Boost обсуждают как стать более привлекательными для пользователей. У кого какие идеи/пожелания?

Куда уж еще более привлекательной? И так все пользуются. Но Илья прав, документацию надо переработать.

Там в Boost обсуждают как стать более привлекательными для пользователей. У кого какие идеи/пожелания?

Побольше модульности и header-only, чтобы ради одного класса не нужно прилинковывать монстра.

Куда уж еще более привлекательной? И так все пользуются. Но Илья прав, документацию надо переработать.

Не все, мы с коллегами пока держимся :)

Побольше модульности и header-only, чтобы ради одного класса не нужно прилинковывать монстра.

я категорически против header-only

Не все, мы с коллегами пока держимся :)

А что у вас? Qt?

А что у вас? Qt?

Насколько возможно, std, немного своих велосипедов. Qt только в и для GUI.

я категорически против header-only

Почему?

Почему?

увеличивает время компиляции

Может увеличивать, а может и не увеличивать (заметным образом).

Может увеличивать, а может и не увеличивать (заметным образом).

в каком случае header-only либа будет собираться быстрее, чем не header-only?

в каком случае header-only либа будет собираться быстрее, чем не header-only?

Когда завезут нормальные модули.

Быстрее - ни в каком

(отметаем случаи, когда нельзя сделать не header-only)

Когда завезут нормальные модули.

на них индустрия не переедет ещё лет 10

БЛИН, АНТОН! Это очень просто. ПРОСТАЯ ДОКУМЕНТАЦИЯ!

Конечно, библиотеки разные, и разного уровня сложности. И документация разная. Но порой она просто сделана на @от@#ись"...

Быстрее - ни в каком

ну вот. тогда я не вижу пользы от них

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

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

Побольше модульности и header-only, чтобы ради одного класса не нужно прилинковывать монстра.

Там и так всё ОК с модульностью...

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

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

Там и так всё ОК с модульностью...

Ага, ставил недавно через vcpkg Boost.MultiIndex, он столько всего притянул! Допускаю, конечно, неоптимально прописанные зависимости в самом vcpkg.

Ага, ставил недавно через vcpkg Boost.MultiIndex, он столько всего притянул! Допускаю, конечно, неоптимально прописанные зависимости в самом vcpkg.

нет. Там всё нормально прописано. просто мультииндекс много чего тянет

я категорически против header-only

Ну там в общем всё ОК с этим, тоже, как я считаю. Если код шаблонный, то headeronly и ок. Если что-то там тяжёлое, типа RegEx, и нешаблонный код -- его не делают header only

пакетированием буста в конан и vcpkg занимался знающий в бусте человек

Конечно, библиотеки разные, и разного уровня сложности. И документация разная. Но порой она просто сделана на @от@#ись"...

Нужно документацию переложить на какую-то платформу где колллаборация возможна, и пользователи могли бы оставлять комментарии в тех местах где им непонятно. У Django 0.9 так были доки сделаны и к каждому абзацу можно было разъяснения и вопросы почитать

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

Я наоборот вижу нашествие телепузиков, для которых всё ядро технологии -- сплошная боль... Ну , это странно...

нет. Там всё нормально прописано. просто мультииндекс много чего тянет

Это же контейнер, он должен быть шаблонный и header-only, а там чуть ли не boost.system тянется, ерунда какая-то.

на них индустрия не переедет ещё лет 10

Грууусна

Это же контейнер, он должен быть шаблонный и header-only, а там чуть ли не boost.system тянется, ерунда какая-то.

почему контейнер должен быть header-only?

потому что он шаблонный?

Ага, ставил недавно через vcpkg Boost.MultiIndex, он столько всего притянул! Допускаю, конечно, неоптимально прописанные зависимости в самом vcpkg.

Это исключение. Очень тяжёлая библиотека. Ничего не попишешь...

потому что он шаблонный?

этого недостаточно

потому что у либы может быть не header-only зависимость

Это же контейнер, он должен быть шаблонный и header-only, а там чуть ли не boost.system тянется, ерунда какая-то.

Так он же и есть header only...

можно, конечно, ещё понаписывать специализаций в .срр, но зачем?..

потому что у либы может быть не header-only зависимость

может, я понимаю, но уж очень странные у него зависимости

всё, дальше скучно спорить.

может, я понимаю, но уж очень странные у него зависимости

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

Конечно, скучно, мы же не спорим, а обсуждаем.

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

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

1) Это увеличивает стоимость поддержки. Если вам это так надо - пишите реквест в Boost Mailing List 2) Я повторю ещё раз - проблема должна решаться не создавнием lite версий либ, а нормальным пакетированием

Что есть "нормальное пакетирование", как вы его видите?

Что есть "нормальное пакетирование", как вы его видите?

как в любом другом нормальном языке программирования

Прости-господи JS с его npm хотя бы

rust + cargo, python2/3 + pip2/3, java + maven, C# + nuget? , много чего ещё

Соласен на 120%, что С++ в заднице по сравнению с, примерно, всеми остальными языками по этому критерию.

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

Соласен на 120%, что С++ в заднице по сравнению с, примерно, всеми остальными языками по этому критерию.

и именно эту проблему надо решать (и она решается как на уровне тулинга, так и на уровне комитета). На уровне комитета резльутатов пока что никаких, на уровне тулинга решения есть. одно вы уже ранее упоминали

Согласен, что нужно эти решения развивать и использовать.

"На уровне комитета резльутатов пока что никаких" - вот это и обидно

чем коммунити и занимается с переменным успехом ?

"На уровне комитета резльутатов пока что никаких" - вот это и обидно

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

Так про модули ещё чуть ли не с принятия С++11 говорят, а результатов всё нет

Так про модули ещё чуть ли не с принятия С++11 говорят, а результатов всё нет

ничего ща уже примут все уже вот вот обещали

Так про модули ещё чуть ли не с принятия С++11 говорят, а результатов всё нет

потому что эта фича очень сложно идёт из-за всяких проблем с существующим кодом и проработкой всех corner cases. Если всё выгорит как надо, то получим в С++20. Если не повезёт, то в С++23

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

Блин, MultiIndex -- это супербиблиотека, это по сути готовая in-memory СУБД, что ж ты хочешь -то?

потому что эта фича очень сложно идёт из-за всяких проблем с существующим кодом и проработкой всех corner cases. Если всё выгорит как надо, то получим в С++20. Если не повезёт, то в С++23

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

Блин, MultiIndex -- это супербиблиотека, это по сути готовая in-memory СУБД, что ж ты хочешь -то?

Я хочу std::map с двумя или больше ключами, а они мне какого-то монстра суют. Кстати, вы им пользовались? Производительность не сравнивали с тем же std::map (в тех сценариях, на которых возможно сравнение)?

Ага, ставил недавно через vcpkg Boost.MultiIndex, он столько всего притянул! Допускаю, конечно, неоптимально прописанные зависимости в самом vcpkg.

https://cppan.org/pvt.cppan.demo.boost.multi_index/version/1.68.0 список зависимостей

Я, как раз, писал/пишу свою in-memory СУБД, мне просто нужен шаблонный контейнер, и чтобы пошустрее работал. Поэтому, увидев список зависимостей, я приуныл.

https://cppan.org/pvt.cppan.demo.boost.multi_index/version/1.68.0 список зависимостей

Серьезно, boost.multi_index зависит от boost.winapi?

да

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

Я хочу std::map с двумя или больше ключами, а они мне какого-то монстра суют. Кстати, вы им пользовались? Производительность не сравнивали с тем же std::map (в тех сценариях, на которых возможно сравнение)?

Возможно хватит bimap'a (кажется от того же автора), правда под vs2008-2010 она не работала когда смотрел.

Возможно хватит bimap'a (кажется от того же автора), правда под vs2008-2010 она не работала когда смотрел.

Большое спасибо, про Bimap Гугл мне не рассказывал! Сейчас посмотрю.

Ну сам понимаешь из названия, это совсем урезанный вариант multi_index'a. key <=> value и value <=> key.

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

Для бд не хватит bimap

Смотря, что от неё требуется. У меня только два индекса. Но поскольку bimap всё равно основан на multiindex, то, наверное, нет смысла натягивать сову на глобус, а лучше взять базовый multiindex и выразить с его помощью структуру данных более естественно.

(или, как обычно, просто написать свой велосипед, хе-хе)