это хор

https://godbolt.org/g/yVKPKS

оптимизатор может лок выкинуть

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

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

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

ну да

в данном случае guard низзя выкидывать

Я про это же

ой, извините, перепутал собеседников

вот и збс

пойду свой код перепишу

на локгвард

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

на локгвард

может сразу на 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

void*(std::stack<int32_t>*)

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

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

void*(std::stack<int32_t>*)

как правильно будет

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

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

std::map<std::string, void*(std::stack<int32_t>*)> если точнее

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

в скобочках

ору, я определил глобальную переменную в хедере. не работает.

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

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

что за automatic storage

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

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

что за automatic storage

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

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

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

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

?

Кто-нибудь в курсе, когда в стандарте могут появится Concurrent data structures?

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

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

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

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

Шта? то есть их нет??

Кто-нибудь в курсе, когда в стандарте могут появится Concurrent data structures?

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

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

хз - я на этот вопрос не парсил пропозалы

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

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

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

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

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

http://www.boost.org/doc/libs/1_63_0/doc/html/lockfree.html

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

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

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

аааа, вот оно что :)

Надо Хижинскому как-нибудь сказать об этом)

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, который оставляет итераторы валидными.

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

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

Ну так там просто элементы не в одной области памяти лежат

Ну так там просто элементы не в одной области памяти лежат

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