RM
хер тебе
В этом то и прикол
std::shared_ptr<std::unique_ptr<T>>Size: a a a
2020 April 27
АК
RM
или вот тут, обращение к NextID каждый раз ифает инициализацию счётчика (двойная проверка)
Эта функция вызывается не часто
/¯
Artöm Bakri Al-Sarmini
Чтобы использовать 1 вместо 3 нужен еще non_owning_ptr<T>
Ну и вообще, нормальная практика ВСЕГДА T* трактовать как non-owning
АК
Эта функция вызывается не часто
а ты ЗАМЕРЯЛ? а вдруг суммарный оверхед из микроскопического станет БОЛЬШИМ? а? а? а?
АК
всё, хватит с меня дозы дичи на сегодня
O
Казалось бы, вроде каждый оверхед по отдельности микроскопический, а в совокупности?
Уже начал выяснять, у какого из твоих алгоритмов сложность
O(1), а у какого O(0.99)?RM
Уже начал выяснять, у какого из твоих алгоритмов сложность
O(1), а у какого O(0.99)?ахахах
АК
@zamazan4ik почему в конане ни одного function_ref? 😟
AB
Ну и вообще, нормальная практика ВСЕГДА T* трактовать как non-owning
Хорошая практика
AB
@zamazan4ik почему в конане ни одного function_ref? 😟
Всегда рады вашим mr
O
Я ранее спрашивал, есть ли какой нибудь указатель, который способен наблюдать за данными на которые он указывает чтоб в случае если объект разрушился, указатель стал nullptr
Да, есть
RM
@zamazan4ik почему в конане ни одного function_ref? 😟
А вот как считаешь, стоит ли использовать unique_ptr в какой нибудь обертке thread pool'а ? Я спрашиваю не чтоб доебаться, а реально интересуюсь
RM
Это как то сказывается на том, сколько один поток будет ждать завершения работы второго или это мизерно?
AB
У юника есть еще применение как scoped exit
RM
Да, есть
Как называется?
O
Как называется?
АК
А вот как считаешь, стоит ли использовать unique_ptr в какой нибудь обертке thread pool'а ? Я спрашиваю не чтоб доебаться, а реально интересуюсь
каждый умный указатель покрывает вполне конкретные случаи, поэтому нужно смотреть на ситуацию.
тип указателя определяет концепцию владения, нужно исходить из этого
тип указателя определяет концепцию владения, нужно исходить из этого
O
RM