аналог enable_shared_for_this для qt

врядли найдешь, т.к. у Qt'шных смарт-поинтеров немного другой принцип, они базируются на наследовании от QSharedData, т.е. нельзя взять произвольный объект и хотеть его смарт-поинтером как в stl.

Есть QSharedPointer и QSharedDataPointer

return QSharedPointer(this);//???

Только не понятно и опасно твоя затея выглядит, как минимум на первый взгляд.

QSharedDataPointer требует себе наследование от QSharedData, что не то же самое что сабж.

QSharedPointer - таки да, с 4.5 появился (не обратил внимания как-то). pozitiffcat, THIS.

вообще да.

вообще да.

Да опасно, или да, то что ты искал?:)

Интересно всё таки - зачем такие трики?

Интересно всё таки - зачем такие трики?

Присоединяюсь к вопросу.

я таки не искал))
согласен с опасностью такого подхода. кривоватый дизайн получается.

Хм, а может это ночные бдения будят во мне паранойю.

Но вообще я вижу только один кейс - если обьект сам себя отдает в чье-то безраздельное владение, притом уверен что обьект 100% проживет дольше чем он.

На сколько я помню из-за подобных трюков(и отсутсвия weak ptr) мне не удалось подружить Poco и gmock, ну по крайней мере заставить работать всегда.

Возможно где то стоит использовать QWeakPointer ?

Интересно всё таки - зачем такие трики?

И всё же, если не секрет?

Оупс, топиккастер то не ты :)

например фабрика, создает некий экземпляр класса, и мне нужно, что бы указатель на фабрику оказался как weak pointer в новом экземпляре какого-то класса, конечно можно хранить сырой указатель,но хотелось бы как-то быть посовременней. Много где пишут, что нельзя юзать сырые указатели. Вообще занимаюсь проектированием, программированием много лет, являюсь ведущим разработчиком, обычно за памятью следил сам, кое где использовал unique_ptr, но хочется идти в ногу со временем.

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

ну это не совсем то, что описано в ОП. используй слабые ссылки, а еще лучше - строгую иерархию объектов (типа QObject). Бардак в иерархии - всегда путь к ошибкам, даже со смарт-поинтерами. И не забываем, что смарт-поинтер все-таки не бесплатен.

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

ну так получай её у владельца фабрики, который «имеет» её жесткой ссылкой.

владелец фабрики допустим App, так зачем какому-то классу знать про app, что бы получить себе фабрику

а зачем делать фабрику с неопределенным жизненным циклом? если он все-таки определенный, и больше времени жизни порождаемых объектов - то берем сырой ptr и делов.

владелец фабрики допустим App, так зачем какому-то классу знать про app, что бы получить себе фабрику

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

владелец фабрики допустим App, так зачем какому-то классу знать про app, что бы получить себе фабрику

Почему фабрику не сделать синглтоном, доступным из какого-нибудь статического метода?

а если какойто дурак потом обернет этот сырой указатель в smart pointer... поэтому я и хотел бы держать его как weak_ptr

нет, я лютый противник синглтонов

Зачем нужны такие кровавые жертвоприношения ТС?

Не легче ли архитектуру с умом сделать и програмеров по рукам бить за извращения?

а если какойто дурак потом

тогда не надо писать на C++ :) это далеко не единственный способ отстрелить себе конечности.

а какже быть если App реализует интерфейс слушателя какого-либо объекта затем object->addListener(this) ? Причем object принимает только weak_ptr

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