@ProCxx - страница 1443 - Telegram web archive

Aidar

http://en.cppreference.com/w/cpp/memory/shared_ptr If multiple threads of execution access the same shared_ptr without synchronization and any of those accesses uses a non-const member function of shared_ptr then a data race will occur Например, вызов двух операторов присваивания над одним shared_ptr в двух разных потоках приведёт к гонке.

да нет

Aidar

я про atomic_store

Aidar

да я и сейчас могу писать std::atomic<std::shared_ptr<T» если что

Кирилл

да я и сейчас могу писать std::atomic<std::shared_ptr<T» если что

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4162.pdf В предложении есть аргументация (п. 4.1). Но я, к сожалению, не настолько в этом разбираюсь, чтобы привести её здесь.

Кирилл

Если первая часть аргументации понятна, то вторая кажется вкусовщиной.

Sergey

да я и сейчас могу писать std::atomic<std::shared_ptr<T» если что

а как это работать будет вообще

Sergey

чето лол

Aidar

а как это работать будет вообще

я не знаю, оно не должно работать по стандарту

Aidar

но у меня не ругается

Sergey

ну типа это не "настоящий" шаблон, а просто с кучей специализаций конкретных

Sergey

но у меня не ругается

черт не могу вот проверить

Sergey

а так было б норм. смарт-пойнтер, да еще тредсейфовый

Sergey

и наверняка пиздец какой тормозной

Aidar

а нет всетаки ругается

Aidar

все нормально

Aidar

ну типа это не "настоящий" шаблон, а просто с кучей специализаций конкретных

он принимает любой тривиально копируемый клас ващето

Aidar

мелкие юзер дефайнд классы могут быть даже локфри

🐙 Antony

и всетаки хочу новое свойство итератора которое означает умеет ли он говорить что он не end

Итераторы как правило нельзя сделать проверяемыми на end без дополнительных накладных расходов. Поэтому и не добавляют

Egor

Да и непонятно, зачем нужна такая концепция.

Egor

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

Egor

И алгоритму дают пару [begin; end)

Egor

И это может быть как весь контейнер, так и его подотрезок, и алгоритм должен работать одинаково. Так что один и тот же итератор может как быть конечным, так и не быть, в зависимости от контекста.

Aidar

Да и непонятно, зачем нужна такая концепция.

чтобы if(m.find(1))

Aidar

я же не говорю что все итераторы должны так уметь

Aidar

только те которым это не доставит оверхеда

Egor

чтобы if(m.find(1))

Не понял пример

Egor

Можете пояснить?

Aidar

if(m.find(1)!=m.end())

Aidar

эту идею ктото тут давно вкинул

Aidar

мне просто понравилось

Egor

Но ведь в этом случае вы либо делаете find от контейнера (и тогда можете у него же спросить end), либо от пары begin, end и тогда тоже знаете, что такое "конец"

Aidar

Но ведь в этом случае вы либо делаете find от контейнера (и тогда можете у него же спросить end), либо от пары begin, end и тогда тоже знаете, что такое "конец"

контейнс тогда зачем

Egor

Вот-вот

Egor

Так что всё ещё не понимаю, в каких случая может потребоваться узнавать, является ли итератор концом контейнера

Aidar

if(m.find(1)!=m.end())

вот это если что полный отстой сейчас

Egor

if (m.contains(1)) или if (m.count(1)) ?

Aidar

if (m.contains(1)) или if (m.count(1)) ?

разный оверхед кажется

Egor

Зависит от контейнера. В multiset count действительно может тормозить. То есть вы хотите такой сахар для функций, работающих с контейнерами?

Aidar

там еще проблема короче с find я понял

Aidar

он не const же

Aidar

там еще проблема короче с find я понял

все все сломалось всем спасибо я пошел спать

Александр

он не const же

чего? const

Aidar

чего? const

Оно и не конст есть

Aidar

Возвращает итератор неконст

Александр

а, ну это да

Aidar

а, ну это да

Ну и вызовется неконст

Alexander "SonnySlave"

https://bincrafters.github.io/2017/11/10/Updated-Conan-Package-Flow/

Berkus

Пацаны, что это: void f(a, b, c) double a, b, c; { /* code here */ }

это си, древний как мамы K&R

Matwey

это си, древний как мамы K&R

Я однажды собирал код на си, которому больше лет чем мне. Там было такое. Он собрался и упал на старте :(

Крылатый

"Была создана подгруппа Tooling (SG Tooling) в Альбукерке. Возможно что через пол годика можно будет посылать предложения по унификации систем сборок, пакетным менеджерам и прочему."

Крылатый

Ну нихрена себе!