C++ Logo


Advanced search

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

From: Sebastian Wittmeier <wittmeier_at_[hidden]>
Date: Sun, 14 Apr 2024 16:35:37 +0200
type_info is for cases, too, where you can compare the unknown runtime type to a known list of types.   So it provides enough for identifying/confirming those. Afterwards you know your type and already have access to your traits and anything else.     To make this step easier, there could be pattern matching support for std::any.     Or a map of limited specific type ids to a templated callable with the detected type as template parameter.   Doing this would instantiate the template for all types in the list.   -----Ursprüngliche Nachricht----- Von:Sebastian Wittmeier <wittmeier_at_[hidden]> Gesendet:So 14.04.2024 16:13 Betreff:AW: [std-proposals] Extend std::type_info with more information An:std-proposals_at_[hidden]; AFAIU type_info is for code working with any runtime type (even non-class, non-RTTI, no common ancestor base class) to compare for equality or create dynamic data structures (e.g. hashtables) with it. Or to output debug messages with the type name.   One cannot do anything else with those types. So which use would it be to get more type traits?   We cannot construct or copy or call member functions or access member variables.   If we get the compile time type, too, e.g. with a template parameter, then we get all the type traits directly anyway. So the extended type info is for cases, where the type is not known and can be any type. So I cannot imagine any use of the typeinfo (only) extended by 64 trait flags.   If you knew the type is trivially copyable and the size, you could copy an instance. But you do not even get the size.     Extending runtime type information is an ABI break and potentially wasteful for programs with lots of generated types. Compared to RTTI it has to be activated for the whole program, even if just one single library needs it.   For most potential real use cases you would generate runtime data only for classes deriving from a specific base. And this is already possible since the earliest C++ versions.   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:So 14.04.2024 15:51 Betreff:Re: [std-proposals] Extend std::type_info with more information An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Sat, Apr 13, 2024 at 1:43 AM Frederick Virchanza Gotham wrote: > >     If you look at the cppreference webpage for the <type_traits> > header, and discard all the deprecated one's, you're left with a list > of 64 booleans <snip> > class extended_type_info { >     template<typename T> >     friend extended_type_info typeidex(void) noexcept; > protected: >     std::bitset<60u> b; > public: >     bool is_compound() const noexcept { return !is_fundamental(); } >     bool is_member_pointer() const noexcept { return > is_member_function_pointer() || is_member_object_pointer(); } > >     bool has_unique_object_representations() const noexcept { return b[0]; } >     bool has_virtual_destructor() const noexcept { return b[1]; } >     bool is_abstract() const noexcept { return b[2]; } >     bool is_aggregate() const noexcept { return b[3]; } >     bool is_arithmetic() const noexcept { return b[4]; } >     . . . >     . . . >     . . . > }; Is anyone keen on having an extended_type_info which contains a 64-Bit number to record all the boolean type_traits? -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2024-04-14 14:35:39