QScopedPointer

[kamre]

Ну вот есть "просто член класса", агрегатом, не указатель  - он почему-то прекрасно копируется. Интуитивно QScopedPointer - такой же член, который однако может быть и null. И что с того - почему он не копируется? Чему это противоречит? Оригинал владеет своим экземпляром, копия - своим, "уникальность" соблюдена.

Для "такой же член, который однако может быть и null" достаточно std::optional, зачем какие-то умные указатели нужны?

[Igors]

Т.е. Вы сами всё знаете. Отлично .
...
Напишите про это в комитет по стандартизации С++, а то "мужики-то не знают" .

Вы не замечали что люди, поначалу весьма активно спрашивающие, затем покидают форум? Думаю потому что как "источник знаний" (или "живой букварь") любой форум малоэффективен. Хотя бы эта тема - ну вряд ли кто-то из присутствующих чего-то "не знал" Но интересны не "знания" (которые проще почерпнуть из справочника), а мысли и оценки - какое решение оптимально в данной ситуации и почему? А Вы шпарите "по книжке" 

Для "такой же член, который однако может быть и null" достаточно std::optional, зачем какие-то умные указатели нужны?

Разумно, но эта замена не эквивалентна. Напр QScopedPointer может указывать на полиморфный тип. Вообще чисто технически "выйгрышь" от него невелик - подумашь, сэкономил строчку в деструкторе, по сути и все. Правда есть ценная возможность swap - ну это редко. Главное что объявив QScopedPointer я четко заявляю "владение", это вносит ясность которой "просто указатель" не имеет.

Почему велик-то? В программе же объявляются типы для хранения данных и формирования нужного поведения.
Это такой же пользовательский тип, как и все другие. Назовите его не указателем (тем более, что желаемая сущность им и не является), а HeapInstance или HeapOptional, например.

Я назвал CDeepPointer, сделал ро образцу ::any c помощью Вашей и _Bers (спасибо товарищам). К сожалению, проблемы "легализации" или "статуса" довольно болезненны. Поэтому в основном все равно используются решения которые, на мой взгляд, объективно хуже, но стандартны и поэтому всем понятны. Напр в данном случае - перекрыть конструктор копирования, что бывает не так уж тривиально (см замечание про полиморфный тип)

[ssoft]

Главное что объявив QScopedPointer я четко заявляю "владение", это вносит ясность которой "просто указатель" не имеет.

QScopedPointer - не является контейнером, а является указателем (ассоциативной связью). А точнее, является уникальным указателем на экземпляр объекта (отсюда и все запреты на копирование и т.п.).
"Владение" в данном случае - это побочный эффект, связанный с необходимостью управлять временем жизни экземпляра объекта, чтобы не было утечек памяти.
При неограниченных ресурсах такой указатель мог бы и не "владеть" экземпляром.

А вот для контейнера (композитного агрегатора) "владение" является неотъемлемой частью его сущности.
Так как агрегация - это частный случай ассоциации, то она может быть реализована на основе любого вида указателей (raw, unique/scoped, shared и т.п.).

Я назвал CDeepPointer, сделал ро образцу ::any c помощью Вашей и _Bers (спасибо товарищам).

Ну и правильно 

[ViTech]

Но интересны не "знания" (которые проще почерпнуть из справочника), а мысли и оценки - какое решение оптимально в данной ситуации и почему?

  Отличный заряд бодрости до конца дня. Спасибо! Эта фраза, произнесённая Вашими устами, звучит особенно пикантно. Ведь все Ваши темы начинаются с сообщения, в котором детальнейшим образом описаны поставленная задача, конкретная ситуация и критерии оптимальности. А название темы подобрано так кратко и ёмко, что уже только по нему можно предложить оптимальное решение.

Я назвал CDeepPointer, сделал ро образцу ::any c помощью Вашей и _Bers (спасибо товарищам).

Робкий вопрос из зала: "А это разве не велосипед?". Ведь:

Но тут эффект что я не раз наблюдал: нужно именно "стандартный" (вумный) указатель, хочет человек или нет, а справочник откроет, жизнь заставит. А "велик" может быть самый распрекрасный, но.. другим-то надо в него вникать, да еще и с нуля и без доки, это вызывает недовольство.

В CDeepPointer вникать не надо, он вызывает довольство?

[Igors]

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

Дв, "краткость - сестра таланта" 

Робкий вопрос из зала: "А это разве не велосипед?".
...
В CDeepPointer вникать не надо, он вызывает довольство?

Точно так же как и Ваши творения Как же Вы посмели (а ведь посмели) предложить свою собсную трактовку вумных указателей? Это что, выходит все что мы так добросовестно учили - оказывается вяло, блекло, маловыразительно, "сущностей" никак не выражает, да и вообще "бедно"? Та не может быть!!! Там же (в комитете?) такие вумные дядьки, они плюсы знают в 100 раз лучше! А этот крендель/чувак кто? Он че, такой умный? И.т.п. (уже с переходом на личности)

Это совершенно нормальная, естественная реакция на абсолютно ЛЮБУЮ самостоятельную мысль/решение. Человека можно понять, он "учил", тратил свое время и силы (читай - запоминал), признать что это "не совсем то" или хотя бы "всего лишь один шаг к истине" посильно немногим. Ну и объективные основания есть. Требовать знания std - вполне можно, а вот знания/понимания моих (Ваших, еще кого-то) личных наработок - нет. Все-таки программирование во многом технология/конвейер, и считаться с этим приходится

[ViTech]

Дв, "краткость - сестра таланта" 

Талантище тогда у Вас просто огроменного размера .

Точно так же как и Ваши творения Как же Вы посмели (а ведь посмели) предложить свою собсную трактовку вумных указателей? Это что, выходит все что мы так добросовестно учили - оказывается вяло, блекло, маловыразительно, "сущностей" никак не выражает, да и вообще "бедно"? Та не может быть!!! Там же (в комитете?) такие вумные дядьки, они плюсы знают в 100 раз лучше! А этот крендель/чувак кто? Он че, такой умный? И.т.п. (уже с переходом на личности)

Это совершенно нормальная, естественная реакция на абсолютно ЛЮБУЮ самостоятельную мысль/решение. Человека можно понять, он "учил", тратил свое время и силы (читай - запоминал), признать что это "не совсем то" или хотя бы "всего лишь один шаг к истине" посильно немногим. Ну и объективные основания есть. Требовать знания std - вполне можно, а вот знания/понимания моих (Ваших, еще кого-то) личных наработок - нет. Все-таки программирование во многом технология/конвейер, и считаться с этим приходится

К чему этот плач Ярославны? Я говорил о том, что сначала Вы на предложение сделать класс с нужным поведением сетуете, что это велосипед, нужно вникать, вызывает недовольство, потом ровно такой велосипед и делаете. Непоследовательно как-то. Не ново и не интересно. Предложили бы какой-нибудь крышесносящий вариант, чтобы мы тут все ох...фигели .

[kamre]

Для "такой же член, который однако может быть и null" достаточно std::optional, зачем какие-то умные указатели нужны?

Разумно, но эта замена не эквивалентна. Напр QScopedPointer может указывать на полиморфный тип.

А как можно скопировать объект произвольного полиморфного типа, имея только указатель на базовый класс?

[ssoft]

А как можно скопировать объект произвольного полиморфного типа, имея только указатель на базовый класс?

Подобно, как это делает std::any со встроенной фабрикой.

[Igors]

А как можно скопировать объект произвольного полиморфного типа, имея только указатель на базовый класс?

Название не помню, но это тот же паттерн что и в QVariant, boost::any а может и где еще

[kamre]

Название не помню, но это тот же паттерн что и в QVariant, boost::any а может и где еще

Так они же по значению принимают и хранят объект, а не по указателю как smart pointers.

Видимо в этой теме имеется ввиду какой-то аналог std::any, который ограничивает тип объекта, который хранит. Но инициализировать такой аналог указателем уже нельзя будет.