brutal hack to support std::variant

[ab9rf]

this is a fairly brutal hack to allow std::variant to appear in structures

the attribute raw-type is used to specify the C++ type string that will appear between the brackets when instantiating the type. no processing of this type is done by codegen. note that < and > are special in XML and will have to be substituted by < and >

note also that this does not deal with identity trait issues at all; an OPAQUE_IDENTITY_TRAIT will be needed to be added to DataIdentity.h and DataIdentity.cpp for each specialization of std::variant that results from the use of this specification

[cvuchener]

Does this have any use? I don't see any variant in the current structures xml.

[myk002]

we're prepping for 50.12, which does use std::variant. Note that 50.12 is not imminent. We're just working off an intermediate build that Toady shared with us.

[ab9rf]

Does this have any use? I don't see any variant in the current structures xml.

there actually are several std::variants in the current structures, but they're "hidden" by representing them as a tagged union followed by the discriminator tag, which is how std::variant is implemented by the STL implementations of both MSVC and gcc. however, this only works if the constituent types have trivial destructors (which is required for the union itself to have a destructor), which all of the std::variants in 50.10 and 50.11 have had. however, 50.12 is currently anticipated to introduce a std::variant with a constituent type that has a nontrivial destructor (specifically, std::string), and so for our virtual identity stuff to work correctly in this circumstance we have to have it actually be a std::variant so the compiler will be able to adduce a valid destructor for the reconstructed synthetic type, and thus we are adding the ability for codegen to generate objects whose type is a specialization of std::variant. there are other ways we could have solved this, admittedly, but this seemed the most straightforward.

a better approach to specifying the type parameters of the std::variant is planned (as well as the ability to specify all of the type parameters of std::function and std::map), but that will require some fairly serious revisions to codegen and codegen is not easy to work with. most of the logic involved is buried in the two XSL transforms and i have to say that there's lot in there i don't understand well enough to tinker with it at that level yet

[cvuchener]

a better approach to specifying the type parameters of the std::variant is planned (as well as the ability to specify all of the type parameters of std::function and std::map), but that will require some fairly serious revisions to codegen and codegen is not easy to work with. most of the logic involved is buried in the two XSL transforms and i have to say that there's lot in there i don't understand well enough to tinker with it at that level yet

50.12 beta is now public. So what is the plan? I'd like to add support df-structures 50.12 in my own library.

[myk002]

our working solution is in the 5012-beta branches (both for dfhack and df-structures), but actual templated types is not yet implemented

[ab9rf]

i've been thinking about how to do this over the past few weeks and have a kernel of a plan but i need to do some experimentation first. it may be a few weeks before a concrete proposal emerges

note i am not claiming ownership of this problem and am more than willing to look at any reasonable approaches here. it has been over a decade since i did anything substantial with XSDs or XSLs and the rust here is very thick

[ab9rf]

at the moment i'm looking at something akin to this:

<template-instance template-name='name'>
contents are then either
<type-parameter>
a simple type
or
a compound (which will be redued to a T_ type and used as the parameter)
or
a subordinate template-instance (for nested template instances)
</type-parameter>
or
<type-parameter type-name='...'/> which is a shorthand
this is repeated as many times as appropriate
</template-instance>

<stl-variant> would then be an alias for <template-instance template-name='std::variant'>

there's a further extension (to be done later) for dealing with function types (which is what the type parameter of std::function is) that i'm thinking will be repurposing the existing vmethod tag

we'll probably eventually want to be able to declare templates as well; there is at least one template type in g_src now -- we're ignoring that it's a template because all of the instances are binary-compatible so we can pretend they're all the same type, but this can't be counted on being the case forever, but this isn't immediately needed so that's a future thought

anyway, thoughts welcome none of this is set in stone, and i got nowhere when i tried a first pass at implementing this yesterday so i'm still at square one in this regard

[cvuchener]

Thanks for the information. It looks fine for my usage. I cannot help with the codegen part though, I never looked up how it worked in details.