Date: Sat, 5 Dec 2020 17:13:49 +0200
The Reflection TS (See N4856) should address this, as far as I understand.
On Sat, Dec 5, 2020 at 4:52 PM Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Sat, Dec 5, 2020 at 9:05 AM darkdragon via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> It would be awesome if a constexpr version of hash_code() and
>> preferably name() would be included in the standard. Is there anything
>> more constexpr than type_info?
>>
>
> Sadly, yes; `type_info` is intimately tied up with RTTI, and many
> implementations implement type_info::operator== as a string-comparison of
> the names of the types, so that it'll keep working even in the presence of
> dynamically linked libraries (DLLs).
>
> So your goal might not be literally *impossible*, but it won't be
> trivial, either.
>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
On Sat, Dec 5, 2020 at 4:52 PM Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On Sat, Dec 5, 2020 at 9:05 AM darkdragon via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> It would be awesome if a constexpr version of hash_code() and
>> preferably name() would be included in the standard. Is there anything
>> more constexpr than type_info?
>>
>
> Sadly, yes; `type_info` is intimately tied up with RTTI, and many
> implementations implement type_info::operator== as a string-comparison of
> the names of the types, so that it'll keep working even in the presence of
> dynamically linked libraries (DLLs).
>
> So your goal might not be literally *impossible*, but it won't be
> trivial, either.
>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2020-12-05 09:14:33