[Development] parented_ptr

[André Somers]

On 05-11-2025 09:10, Arno Rehn wrote:
> On 05.11.2025 08:22, Daniel Schürmann wrote:
>> However I am not confident that this bullet proved enough for being 
>> integrated in the upstream library.
>> * It works by guessing the parent argument which can fail at runtime 
>> without even a compiler message, in users code.
>> * It does not yet (<x++23) support constructors requiring a sub 
>> class parent like QWidget or any other user defined sub class.
>> * We can make it more robust by constructing without parent and then 
>> call setParent() causing some extra calls and bookkeeping. I 
>> don't want that.
>
> Honestly I think you're over-engineering this somewhat. "parent comes 
> last" is an established convention when dealing with QObject-derived 
> classes. QWidgets are the same, see for example QPushButton:
>
>     QPushButton(const QIcon &icon, const QString &text, QWidget *parent)
>
> Just forward the args and append "this" as the last parameter to pass 
> the parent along.

Problem is, I guess, that while it is a convention, it is not true 100% 
of the time. Not even in Qt. See QWidget for instance as a counterexample:

     [explicit] QWidget::QWidget(QWidget *parent = nullptr, 
Qt::WindowFlags f = Qt::WindowFlags())

For customer code, you can't be sure people followed this convention at 
all of course.

>
> Re subclass parents: You don't actually need C++23 for that. We can 
> (ab-)use a templated implicit conversion operator to auto-cast a type 
> to the one required by the constructor:

Wow... that looks... dirty. My kind of dirty trick.

Cheers,

André