Thread overview
equivalent of typeid(Class).name at compile-time
Nov 21, 2019
Adam D. Ruppe
Nov 22, 2019
Alexandru Ermicioi
Nov 22, 2019
Jacob Carlborg
November 21, 2019
I thought I could do typeid(Class).name to get the class name that will be returned at runtime if you did typeid(instance).name. But it's not accessible at compile-time.

What compile-time string should I use for instance in a constructed switch statement? I'm trying to implement serialization and deserialization of classes, but I really would like to avoid using a class enum if possible, since the type id is already there and generated by the compiler.

-Steve
November 21, 2019
On 11/21/19 3:44 PM, Steven Schveighoffer wrote:
> I thought I could do typeid(Class).name to get the class name that will be returned at runtime if you did typeid(instance).name. But it's not accessible at compile-time.
> 
> What compile-time string should I use for instance in a constructed switch statement? I'm trying to implement serialization and deserialization of classes, but I really would like to avoid using a class enum if possible, since the type id is already there and generated by the compiler.

To clarify, I need the compile time string that will match typeid(instance).name, so I can match the derived type.

-Steve
November 21, 2019
On Thursday, 21 November 2019 at 20:45:16 UTC, Steven Schveighoffer wrote:
> To clarify, I need the compile time string that will match typeid(instance).name, so I can match the derived type.

You have to make sure that the derived type is passed to your register function, but then std.traits.fullyQualifiedName!T ought to give it to you.
November 22, 2019
On Thursday, 21 November 2019 at 20:44:19 UTC, Steven Schveighoffer wrote:
> I thought I could do typeid(Class).name to get the class name that will be returned at runtime if you did typeid(instance).name. But it's not accessible at compile-time.
>
> What compile-time string should I use for instance in a constructed switch statement? I'm trying to implement serialization and deserialization of classes, but I really would like to avoid using a class enum if possible, since the type id is already there and generated by the compiler.

I solved that by storing the class info as the key in an associative array [1]. But it looks like Adam's solution will work as well.

If you ideas, you can always have a look at Orange.

[1] https://github.com/jacob-carlborg/orange/blob/90f1dbb0097ba4a319805bfb7d109f7038418ac6/orange/serialization/Serializer.d#L241-L262
November 22, 2019
On Thursday, 21 November 2019 at 20:48:03 UTC, Adam D. Ruppe wrote:
> On Thursday, 21 November 2019 at 20:45:16 UTC, Steven Schveighoffer wrote:
>> To clarify, I need the compile time string that will match typeid(instance).name, so I can match the derived type.
>
> You have to make sure that the derived type is passed to your register function, but then std.traits.fullyQualifiedName!T ought to give it to you.

Please note that fullyQualifiedName can return slightly different string than ClassInfo.name for templated types (typeinfo returns names that are fully expanded for eponymous templates while FQN function does not) and hence won't recommend mixing both of them toghether.

Best regards,
Alexandru.
November 22, 2019
On 11/22/19 4:04 AM, Jacob Carlborg wrote:
> On Thursday, 21 November 2019 at 20:44:19 UTC, Steven Schveighoffer wrote:
>> I thought I could do typeid(Class).name to get the class name that will be returned at runtime if you did typeid(instance).name. But it's not accessible at compile-time.
>>
>> What compile-time string should I use for instance in a constructed switch statement? I'm trying to implement serialization and deserialization of classes, but I really would like to avoid using a class enum if possible, since the type id is already there and generated by the compiler.
> 
> I solved that by storing the class info as the key in an associative array [1]. But it looks like Adam's solution will work as well.
> 
> If you ideas, you can always have a look at Orange.
> 
> [1] https://github.com/jacob-carlborg/orange/blob/90f1dbb0097ba4a319805bfb7d109f7038418ac6/orange/serialization/Serializer.d#L241-L262 
> 

Thanks for all the replies, guys. Annoying that the compiler has generated these names but doesn't make them accessible at compile-time.

-Steve