C++ Object Token Library

[_Bers]

Используйте конкретный термин "not thread-safe" - ведь именно его Вы имели ввиду.
Даже если бы это и было так, это не может быть основанием "невозможности", просто пишем что данный класс/фича "not thread-safe",
и спокойно ее юзаем.
Да, если дело дойдет до multi-threading - придется прилагать усилия, лочить и.т.п.
Но это обычная работа которую приходится делать во многих случаях, нередко и с "продленным" weak.

для однопоточного случая используй обычный голый указатель - никакой разницы.

Эту песню я слышал много раз.
Голые указатели = плохо. Давайте сделаем все указатели вумными! И будет счастье!
Ну а поскольку возможности юника на практическом нуле - остается делать все shared.
Вас не смущает что это чисто ход мысли начинающего?
Что давать такие советы не требует никакого (ну совсем никакого) ума?
Вы сами-то пробовали так делать? И что, хорошо получилось?
Может лучше поменять взад на голые? 

ты вообще понимаешь зачем нужны умные указатели?
если умный указатель не даёт никаких приимуществ по сравнению с обычным сырым указателем,
то нахера он нужен?

Да, и чисто технически "продлить юник" несложно. Причем используя совершенно легальные средства предоставляемые std.
Несколькими постами выше ViTech кинул ссылочку, интересно - почитаете.

остановок "туда" и "здеся" не существует.
существуют только конкретные остановки.
и конкретные ссылки.

[ViTech]

И где тут "weak становится expired, когда unique помирает"?

зачем он нужен?

Быстро же вы ответы изменяете )).

Я так понял: "зачем ... нужен?" - это ваш коронный вопрос. А зачем нужен std::weak_ptr::expired()?

[_Bers]

Быстро же вы ответы изменяете )).

я пришел к выводу, что для std::unique_ptr нельзя без приседаний получить pointer&
а значит для поддержки expired потребуется совершить некоторые телодвижения.

сразу закономерный вопрос: нафига это нужно?

Я так понял: "зачем ... нужен?" - это ваш коронный вопрос. А зачем нужен std::weak_ptr::expired()?

очень правильный вопрос.
дело в том, что std::weak_ptr::expired() - это очень вредный метод

это - зло, ставшее причиной множества багов.

у этого зла есть имя: "функционал, который даёт ложное чувство безопасности"

я сам лично неоднократно встречал такой код:

Код:

if(!weak.expired())
    weak.lock()->work();  // <--- баг

weak не контролирует время жизни ресурса.
то, что он ещё не протух, не значит, что не протухнет в след. мгновение.


правильный код должен быть:

Код:

if(!weak.expired())
{
    auto shared = weak.lock();
    if(shared)
       shared ->work();  // <--- ok
}

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

так зачем же все таки нужен метод weak_ptr::expired() ?
собака зарыта в методе lock.
lock лочит разделяемые между потоками данные shared.
что как известно - не бесплатно.

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

Код:

if(!weak.expired())  // <--- быстрая проверка
{
    auto shared = weak.lock();  // <--- медленный лок

    if(shared) // <--- окончательная проверка
       shared ->work();  // <--- можно работать
}

[ViTech]

weak не контролирует время жизни ресурса.
то, что он ещё не протух, не значит, что не протухнет в след. мгновение.

Зато если он протух, это признак того, что объект помер и можно выполнить соответствующие похоронные действия. Или ничего не делать. Вот и весь функционал expired, не более.

[_Bers]

weak не контролирует время жизни ресурса.
то, что он ещё не протух, не значит, что не протухнет в след. мгновение.

Зато если он протух, это признак того, что объект помер и можно выполнить соответствующие похоронные действия. Или ничего не делать. Вот и весь функционал expired, не более.

его завезли только ради возможности не лочить шаред зазря.

если бы получение шареда было быстрым,
тогда expired бы сейчас не существовало.

[Old]

Зато если он протух, это признак того, что объект помер и можно выполнить соответствующие похоронные действия. Или ничего не делать. Вот и весь функционал expired, не более.

Ну так в однопоточном режиме expired юника как раз:

Код

C++ (Qt)
if( (auto p = unique_ptr.get()) )
{
  p->do();
  p->bar();
}
 

Пока вы контролируете поток исполнения вы видите в каком месте этот юник может умереть. И если такой момент присутствует, то просто проверяете валидность указателя после него еще раз.
В однопоточной среде с этим нет никаких проблем.

[_Bers]

Зато если он протух, это признак того, что объект помер и можно выполнить соответствующие похоронные действия. Или ничего не делать. Вот и весь функционал expired, не более.

Ну так в однопоточном режиме expired юника как раз:

Код

C++ (Qt)
if( (auto p = unique_ptr.get()) )
{
  p->do();
  p->bar();
}
 

Пока вы контролируете поток исполнения вы видите в каком месте этот юник может умереть. И если такой момент присутствует, то просто проверяете валидность указателя после него еще раз.
В однопоточной среде с этим нет никаких проблем.

хочется держать сам юник в одном месте,
а вики на него - в 10 других местах.

и вот в этих местах нужно знать: протух ресурс, или нет.


грубо говоря, можно раздавать обычный сырой указатель на сам юник.
и через этот указатель спрашивать: "ты там живой ещё?"

если же сам юник протухнет,
считай что его вики в виде сырых указателей так же протухли

Код:

auto*& example::get_weak()
{
    return &owner; // std::unique_ptr<some>
}

[ViTech]

его завезли только ради возможности не лочить шаред зазря.

если бы получение шареда было быстрым,
тогда expired бы сейчас не существовало.

Когда шаред залочить не получается, это тоже признак того, что объект помер, и weak находится в состоянии "expired". Т.е. условно проверка weak на bool в if() направит в ветку else. Вот эта функциональность и нужна: узнать, что объект помер.

Ну так в однопоточном режиме expired юника как раз:

Код

C++ (Qt)
if( (auto p = unique_ptr.get()) )
{
  p->do();
  p->bar();
}
 

Пока вы контролируете поток исполнения вы видите в каком месте этот юник может умереть. И если такой момент присутствует, то просто проверяете валидность указателя после него еще раз.
В однопоточной среде с этим нет никаких проблем.

А если объекты и связи между ними создаются и удаляются динамически? По-моему, проблемы могут возникнуть.

[Old]

хочется держать сам юник в одном месте,
а вики на него - в 10 других местах.

А тут возникает следующая проблема. Мы держим сырой указатель на юник, а в процессе выполнения разрушается объект, который хранил этот юник и указатель становится не валидным.

Придется добавлять свой умный указатель и шарить юник. Так зачем шарить юник если есть shared.

[Old]

А если объекты и связи между ними создаются и удаляются динамически? По-моему, проблемы могут возникнуть.

Ну так в однопоточной среде можно проверить еще раз:

Код

C++ (Qt)
if( (auto p = unique_ptr.get()) )
{
  p->do();
  p->bar();
}
 
xrenEgoZnaet();
 
// Проверяем повторно
if( (auto p = unique_ptr.get()) )
{
  p->foo();
  p->bla();
}
 

[_Bers]

хочется держать сам юник в одном месте,
а вики на него - в 10 других местах.

А тут возникает следующая проблема. Мы держим сырой указатель на юник, а в процессе выполнения разрушается объект, который хранил этот юник и указатель становится не валидным.

Придется добавлять свой умный указатель и шарить юник. Так зачем шарить юник если есть shared.

ну вот они не хотят ничего не шарить.

а хотят просто получить вик с юника,
который им скажет: протух ресурс или нет?

Код:

if(weak)
    weak->work();  // то, что это не безопасно, их не смущает. 

[ViTech]

Ну так в однопоточной среде можно проверить еще раз:
...

Вот пример задачи Car. Даже для однопоточного варианта, какое решение предложите?

[_Bers]

Ну так в однопоточной среде можно проверить еще раз:
...

Вот пример задачи Car. Даже для однопоточного варианта, какое решение предложите?

формулировка задачи: "один движок - много мониторов"
"один ресурс - множество потребителей" - привет, shared!

[ViTech]

формулировка задачи: "один движок - много мониторов"
"один ресурс - множество потребителей" - привет, shared!

Я и не сомневался. Но там и другие требования есть. Например:
Один Engine можно установить только в один Car. Установка одного и того же Engine в несколько разных Car недопустима.

Как его соблюдать предлагаете?

[Old]

Вот пример задачи Car. Даже для однопоточного варианта, какое решение предложите?

То что в стандартной библиотеке нет указателей с необходимыми свойствами я не спорю.
Я подумаю еще над задачей, но на первый взгляд я бы использовал shared с какой нибудь проверкой на количество в рантайм.
Но я подумаю.