А ничего кросс-платформенного человечество ещё не придумало? Гугловцы же полюбому как-то билдят хром/хромиум под винду распределённо

Fastbuild?

хром не так долго собирается на нормальной рабочей станции

Хм, ну мне кажется не меньше часа для чистой сборки

(это из своего опыта, на моём ноуте хромиум ~5 часов собирался, но у меня нет SSD, только 12ГБ оперативы)

Fastbuild?

Хм, выглядит интересно, осталось понять в чём подвох ?

Хм, выглядит интересно, осталось понять в чём подвох ?

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

А почему в std::shared_ptr убрали метод unique ?

> This function was deprecated in C++17 and removed in C++20 because use_count is only an approximation in multithreaded environment (see Notes in use_count)

А почему не переделали в detach_unique_ptr?

А почему в std::shared_ptr убрали метод unique ?

Нет возможности атомарно проверить и что-то сделать на основе этого, емнип. Или я перепутал с use_count

Нет возможности атомарно проверить и что-то сделать на основе этого, емнип. Или я перепутал с use_count

Я могу compare_exchange_strong(use_count, 1, 0);

Хочу прямо таки вытащить unique_ptr из shared_ptr

Я могу compare_exchange_strong(use_count, 1, 0);

Так он ж значение возвращает не атомик, которое уже через миг может быть изменено кем-то. Но судя по всему я не совсем в теме вопроса

Так он ж значение возвращает не атомик, которое уже через миг может быть изменено кем-то. Но судя по всему я не совсем в теме вопроса

Он возвращает не атомик, понятно, что нельзя просто сделать if (ptr.use_count() == 1) в многопоточной среде и думать, что в следующей строке use_count() не 2 Вопрос что если я его вытаскиваю, этой проблемы нет, все weak - ссылки отныне считают его nullptr

Хочу прямо таки вытащить unique_ptr из shared_ptr

это противоречит дизайну шаред в общем случае

это противоречит дизайну шаред в общем случае

каким образом?

он там с кем то расшарился. юником ресурс уже не сделаешь

Он возвращает не атомик, понятно, что нельзя просто сделать if (ptr.use_count() == 1) в многопоточной среде и думать, что в следующей строке use_count() не 2 Вопрос что если я его вытаскиваю, этой проблемы нет, все weak - ссылки отныне считают его nullptr

Наверное, это можно сделать методом try_extract_unique, который может быть реализован (разрабами stl, конечно). Почему не сделали - хз.

он там с кем то расшарился. юником ресурс уже не сделаешь

почему?

потому что это противоречит дизайну.

почему?

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

кажется, да

тогда должег почему шаред внезапно может расшариццо

если на него нет weakref и strongref равен 1 он никогда не может расшариться так уж внезапно

если вам не нужно шарить, значит вам не нужен шаред. можете сразу брать юник

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

он имеет право разрушить объект

локай, копируй.

это асимптотически ухудшает код

почти всегда счетчик равен 1

@graninas врывайся в тред: http://eao197.blogspot.com/2018/07/progflame.html

@graninas врывайся в тред: http://eao197.blogspot.com/2018/07/progflame.html

Пахнет жареным.

ну так ЛОР же

@graninas врывайся в тред: http://eao197.blogspot.com/2018/07/progflame.html

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

это асимптотически ухудшает код

за пределами здравого смысла ничем не могу помочь

за пределами здравого смысла ничем не могу помочь

вашего? :) это глобальные персистентные модели данных

shared_ptr<const T> без non-const ссылок используется в качестве типа-значения

при запросе модификации данных создается копия, лишняя копия 1М памяти под неатомарно записанную операцию это такое

наиболее естественная реализация выглядит как вытаскивание данных из shared

вторая по естественности - использование policy-based intrusive с явным указанием возможности многопоточности, вычисленного по целевому типу

наиболее естественная реализация выглядит как вытаскивание данных из shared

естественным будет шарить там, где это нужно по смыслу. либо не шарить вообще. остальное отдаёт уг

вы понимаете, что такое персистентные структуры данных?

https://en.wikipedia.org/wiki/Persistent_data_structure

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

Даже с методом unique() Вам же еще нужен метод release, а его у shared_ptr нет.

@graninas врывайся в тред: http://eao197.blogspot.com/2018/07/progflame.html

Да я видел.

Даже с методом unique() Вам же еще нужен метод release, а его у shared_ptr нет.

Пойду пропозить)

Пойду пропозить)

Что именно?

Плоховато Евгений набрасывает. Все "аргументы" я уже тысячу раз слышпл, хоть бы новых придумали

Что именно?

грубо говоря unique_ptr<T> release_if_unique() && { if (compare_exchange_strong(use_counter_, 1, 0)) { return { pointer() }; } return {}; }

грубо говоря unique_ptr<T> release_if_unique() && { if (compare_exchange_strong(use_counter_, 1, 0)) { return { pointer() }; } return {}; }

Ну std::default_delete возвращать-то точно нелья, правильно?

Ну std::default_delete возвращать-то точно нелья, правильно?

Почему?

Будет странно, я же клал объект с одним deleter'ом, получаю с другим

А кто очистит блок, если shared_ptr выделялся через std::make_shared?

Будет странно, я же клал объект с одним deleter'ом, получаю с другим

Хм... то есть надо возвращать unique_ptr<T, shared_deleter_wrapper<T>> ?

Это во-первых, + надо вместе с compare_exchange_strong(use_counter_, 1, 0) атомарно проверить, что weak_counter == 0, иначе оставшиеся в живых weak_ptr'ы огорчатся, ведь так?

Мною изначально предполагается, что weak в этом случае должны считать, что lifetime объекта закончился

На самом деле это следствие изначальной модели, в которой weak вообще нет и intrusive подходит лучше

Мною изначально предполагается, что weak в этом случае должны считать, что lifetime объекта закончился

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

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

Я что-то не знаю про weak структуры в случае make_shared? Там аллоцируется один общий блок?

Я что-то не знаю про weak структуры в случае make_shared? Там аллоцируется один общий блок?

да

и он живет, пока жив хоть один shared_ptr или weak_ptr

да

и весь фрагмент памяти держится до последнего weak?

да

если нужно ограбить шаред, и отдать ресурс юнику, то можно грабануть сам ресурс. шаред и уник вообще трогать менять не нужно

да

хотя бы оптимизируют, что если sizeof(object) > 56 то надо два фрагмента выделять?

хотя бы оптимизируют, что если sizeof(object) > 56 то надо два фрагмента выделять?

нет, зачем? а откуда число 56?

нет, зачем? а откуда число 56?

условный параметр на случай 64 alignment для new

чтобы не держать очень большие фрагменты памяти, а держать только маленький

там может и 4K sizeof-ом быть

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

Считается что если у вас большой объект и нужны weak_ptr, то ваша ответственность не пользоваться make_shared https://stackoverflow.com/questions/32113594/weak-ptr-make-shared-and-memory-deallocation

да, я понял

да, в такой модели совершенно точно нужно проверять weak-и

хотя стоп, нет, все еще не обязательно, default_shared_deleter сделает как надо

это же буквальный перенос deleter-а на полученный unique_ptr будет

а, ОЙ

это же буквальный перенос deleter-а на полученный unique_ptr будет

да, кажется, будет работать, только в if тогда не надо уменьшать счеткик до 0, оставить его 1

надо, видимо, еще инкрементить счетчик weak

т.е. strongref в 0, weakref++

чтобы нам последний weak_ptr не грохнул блок

нужно найти второй use case или делать отдельный параметр/функцию для поведения при наличии weak - это факт хотя всякие shared_from_this в действительности очень сильно мусорят в weak ref counter

т.е. strongref в 0, weakref++

с одой стороны надо так, с другой, тогда deleter нашего unique_ptr (shared_deleter_wrapper<T>) не вызывет deleter для самого объекта

мы в точности внутрь unique_ptr положим логику, которая отработала бы при смерти shared_ptr

кажется, этого достаточно, чтобы не было проблем

с точностью до того, что будет --weakref вместо --strongref

мы в точности внутрь unique_ptr положим логику, которая отработала бы при смерти shared_ptr

первым делом это логика уменьшает strongref и она очень удивится, что там уже 0

а результат --strongref изначально считается 0

с точностью до того, что будет --weakref вместо --strongref

а, так :) 3-я логика — умирает не shared_ptr и не weak_ptr

кажется, что выходит монстр

хех, на самом деле можно просто pair<old_deleter, weak_ptr> положить

и вызвать old_deleter(), а потом отпустить weak_ptr

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

это суперпринципиальная оптимизация, хотя она естественнее для intrusive_ptr, да

или для shared_nonpolymorphic_default_delete_no_weak_support_ptr

или для shared_nonpolymorphic_default_delete_no_weak_support_ptr

это из telegram desktop?