C++ Logo


Advanced search

Re: [std-proposals] Extend std::type_info with more information

From: Thiago Macieira <thiago_at_[hidden]>
Date: Fri, 12 Apr 2024 08:16:43 -0700
On Friday 12 April 2024 07:34:19 GMT-7 Mihail Mihaylov via Std-Proposals
> > OK, you convinced me (kind of). I've been working for years in a code base
> > that has its own any-like object, but I haven't really used `std::any`
> > itself. It took me a while to realize how significant it is that
> > `any_cast`
> > returns a copy instead of a reference. It now seems to me that the
> > designers of `std/boost::any` never meant for polymorphic types to be
> > stored in it and the question about how to get a base out of the stored
> > derived value goes outside of its intended usage.
> Scratch that, it turns out that `any_cast<A>(any*)` returns an `A*` to the
> value inside, which makes it meaningful to request the ability for this
> overload to return a non-null `A*` when the `any` contains a `B` where `B`
> is derived from `A`.

Still, we are talking about storing a polymorphic type inside of std::any and
the general rule of thumb is that an object is EITHER polymorphic or copyable,
not both. Storing an uncopyable object inside of std::any sounds just wrong. I
don't think it supports storing immovable types at all, does it? So this alone
removes the majority of the benefit of this operation, because the types in
question cannot be stored inside std::any in the first place.

In the Qt world, the class that best resembles std::any is QVariant and it
does not support storing uncopyable types.

It does support storing pointers and, if the pointer is to a class derived
from QObject, then it can perform casting back to QObject and to any other
class that derives from it after verifying that this cast would be valid.

Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Principal Engineer - Intel DCAI Cloud Engineering

Received on 2024-04-12 15:16:49