[quot alexy_black]народ, вам не кажется, что шалон enable_shared_from_this сделан плохо?
от него надо наследоваться обязательно public, но это по большому счету не верно, ведь это больше деталь реализации

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

alexy_blackMasterZivконтракта интерфейса с клиентом данного классане понял. то есть если клиенты никогда не вызывают shared_from_this, эта функция вызывается только внутри класса?



Наоборот.

Что ты понимаешь под "контрактом класса" или "интерфейсом" ?
Погугли, почитай.

alexy_blackпро контракты я заню. только в чем тут контракт?

В том, что ты даёш пользователю возможность вызвать с экземпляром класса метод shared_from_this

alexy_black
вот например такой класс не нарушит принципа лиски какой бы указатель тут ни использовался.


Принцип Лисков тут ни при чём.

alexy_blackдальше такой класс может использовать foo_ptr вызываея его методы и все. классу some не нужно знать что foo_field_ - shared_ptr или еще что-нибудь в этом духе. у него есть указатель и ему без раницы какой он.
если например это shared_ptr то перемещение будет полезным, потому что при копировании должно атомарно увеличится значение счетчика, а так просто перемащает указатель.

зачем классу foo иметь публичного предка std::enable_shared_from_this<foo>, если он, например, вызывает shared_from_this только в одной из своих приватных функций?

выходит, я могу, как бы, создать шаблонну функцию принимающюю ссылку на объект std::enable_shared_from_this<T> и вызывать для него shared_from_this. но если я захочу провести рефакторинг, то мне придется это менять.


У тебя тут в примере нет класса, который наследуется от std::enable_shared_from_this .
Так что обсуждать нечего.

И, боюсь, в твоей голове всё очень сильно перемешано, до возникновения лёгкого бардачка...

авторзачем классу foo иметь публичного предка std::enable_shared_from_this<foo>, если он, например, вызывает shared_from_this только в одной из своих приватных функций?

Если классу foo надо вызывать shared_from_this только внутри реализаций своих методов, то очевидно, что это -- фиксированный определённый скоуп, и там shared_ptr просто не нужен вообще. Если shared_from_this вызывается в реализации методов, а результат отдаётся наружу, то это уже становится частью интерфейса этого класса.
Да, в таком случае можно наследоваться от std::enable_shared_from_this непублично.

alexy_blackAnatoly Moskovskyalexy_black,
То что вы предлагаете, подразумевает что каждый юзерский класс должен описывать friend для всех внутренностей shared_ptr.
Это то что я назвал "через одно место"
Хотели большей инкапсуляции, а получили полную зависимость от реализации shared_ptr.вот и выразили смысл моего первого поста.
я бы хотел чтобы можно было добавить какой-нибудь класс в друзья и это бы гарантированно разрешало protected наследование. но в реале так нельзя сделать, потом учто полуится именно что через одно место. это проиходит не из-за ограничений языка, а из-за такой реализации enable_shared_from_this.

а публичное наследование в некоторых случаях логически не верно.

вот то, о чем я тут и пишу :)
я вообще не понимаю ни одного слова из того, что ты пишешь.

да, я не напрягаюсь и читать в метро, но других людей в такой ситуации я как правило понимаю.

вообще, в чем проблема то наследования от ESFT?

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

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

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


Какое ещё сокрытие информации может обеспечить простой указатель?
Ты не данные и не методы по этому указателю рассматриваешь (должен рассматривать) в данном случае, а сам указатель.

У тебя есть два классических способа сослаться в программе на объект: с помощью ссылки, и с помощью указателя.
Сейчас появился ещё один способ -- с помощью умного (разделяемого) указателя. семантика при этом никак не меняется
(меняется способ создания объекта, но тут он ни при чём)-- это просто указатель. О каком таком сокрытии информации тут может ещё идти речь ?

Кроме этого, ещё раз, ты не понял, что тебе говорят.

Если ты обрабатываешь где-то событие на изменение объекта по типу subject/observer, observer при обработке события обязан иметь валидную на всё время обработки этого события ссылку на subject, при этом ссылка эта обязана быть непустая. ПРи этом объект observer не должен управлять временем жизни объекта subject, и , в частности, не может его продлевать.
отсюда следуют две вещи:
ссылка должна быть ссылкой С++, а не указателем, потому что она дожна быть непустой.

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

alexy_blackMasterZiv, почему обсервер не может продлить жизнь объекта?



попросту потому что это не его дело.

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

но это уже выглядит очень странно.

alexy_black, он должен будет "знать" какой именно указатель используется и можно ли в него вобще преобразовать. универсального способа нет. легче просто отказаться от такого преобразования.

да, он ДОЛЖЕН будет знать, какой указатель используется. Просто обязан.