на локгвард

Без локгварда грустно

на локгвард

может сразу на atomic?_))

Если где-нибудь эксепшен вылетит, будет плохо

может сразу на atomic?_))

это ещё как

Думаю, это сделает линкер

есть флаг вроде бы, забыл уже

использовать?

Не стрипать. А зачем?

Не стрипать. А зачем?

может он хочет свой бинарий потом открывать другим бинарём

это ещё как

http://www.cplusplus.com/reference/atomic/atomic/atomic/ тут пример вроде есть

и юзать функционал

-Wl,-whole-archive вроде бы

типа как делаеш бинарий а юзаеш его как либу

типа как делаеш бинарий а юзаеш его как либу

Звучит довольно криво

типа как делаеш бинарий а юзаеш его как либу

как плугин

и юзать функционал

тогда все либы бы убирались как неиспользуемая функция

Звучит довольно криво

ну это си стайл

http://stackoverflow.com/a/27741897/2814617 Со ссылкой на пункт стандарта

https://godbolt.org/g/Gs9H01

там перечислить надо, что включать полностью

мне кажется он функции не удаляет даже если она нигде не вызываетяс

сравните, что будет. в одном случае получите create destroy infix в другом create infix destroy

ну это си стайл

А почему не собрать либу?

side-effect-то будет, но unreferenced temporary будет сразу уничтожен

и то же будет с локом

А почему не собрать либу?

потому что не ты это решаеш =

=)

ты можеш только её зохватить

и то же будет с локом

я же пример привел с -O2 там не выкинул

я же пример привел с -O2 там не выкинул

так в том примере лок вполне себе referenced

side-effect-то будет, но unreferenced temporary будет сразу уничтожен

потому что нет automatic storage переменной, вот и удаляется сразу

убери референс и посмотри на время жизни

* не в скобочках должен быть?

потому что нет automatic storage переменной, вот и удаляется сразу

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

что за automatic storage

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

в примере ранее был оч макетный код

что за automatic storage

http://en.cppreference.com/w/cpp/language/storage_duration

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

не создавался же, там вообще не видно что до и что после

ну вы знаете кто-то должен был сказать это

👌

крутой вопрос :)

я думаю для начала бы этим структурам вообще появится.

да чтобы еще и без шанса загреметь за очередной патент =(

А были пропозалы?

Они крайне кастомные. я не знаю таких которые бы работали "униврсально хорошо"

а структура хэша которая только для трех тридов - это ок, конечно, но в STL довольно стремно такое тащить

хотя признаться мне был бы интересен std::unorered_map где мьютекс стоит на рехаш, а далее гранулярные мьютексы на бакеты.

+ там жесть с патентами, как я отметил выше.

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

да еще тормозное.

spsc в бусте - оно ужасное, оно медленнее naive имплементации в десятки раз =(

Жестоко.

о чем? там ссылка на десяток алгоритмов, spsc - тормозной.

в тырнете - полно тестов, мои тесты дали примерно такое же впечатление.

хотя я уточню, что для меня тормозной, у меня 10-100m действий в секунду.

и даже очередь из того же Concurrent C++ 11 - работает лучше :)

хотя она там тоже не все кейсы учитывает....

а пифоманс хэшей, отдельная тема, вот есть крутая штука: https://probablydance.com/2017/02/26/i-wrote-the-fastest-hashtable/

а libcds Хижинского крутая штука, почему его не втащить в проект, но для стандарта там все равно много особенностей.

Я помню была старая статья, вот такая - http://incise.org/hash-table-benchmarks.html

Там хуже бустового хеша был только ruby хэш :)

угу, это напалм :)

Интересно их было бы сравнить сейчас

хэши вообще дьявольщина.

а когда тебе надо жесткие требования по времени выборки - вдвойне дьявольщина.

да чистый конкурент штука очень специфичная, на мой взгляд

нередко грамотно расставленные мутексы на обычном STL контейнере дают очень приличные результаты

у меня тут тест завалялся

std::map: 1.9 mega ops per second tbb::concurrent_unordered_map: 1.7 mega ops per second boost::unordered_map: 1.7 mega ops per second boost::container::flat_map with preallocated elements: 3.6 mega ops per second std::unordered_map C++11: 4.5 mega ops per second std::unordered_map C++11 preallocated buckets: 8.3 mega ops per second google:dense_hashmap preallocated buckets: 18.7 mega ops per second std::vector preallocated: 18.8 mega ops per second

а чем flat map примечателен?

Тут вспомнил, пару дней назад был холивар на тему инвалидации итераторов при изменении контейнера, как реализовать и почему нет. Вспомнил про boost::container::stable_vector, который оставляет итераторы валидными.

Кэш юзается нормально

Т.е. вектор, но лист? :D

и вектор векторов

и вектор векторов вектора

по чанкам порубили?

О, канкаррент. Атомики завезли, бартера памяти тоже, можно и локфри канкаррент контейнеры

Народ а подскажите как грамотно добавить объект в std::map<int, A> еслиу меня есть функция которая создает unique_ptr на этот объект - pA? Emplace это же через вызов конструктора насколько я понимаю. Он не подходит?

Народ а подскажите как грамотно добавить объект в std::map<int, A> еслиу меня есть функция которая создает unique_ptr на этот объект - pA? Emplace это же через вызов конструктора насколько я понимаю. Он не подходит?

ну эмплейс да

и в конструктор закидуеш свой объект