On Tuesday, 15 October 2013 at 13:14:46 UTC, Benjamin Thaut wrote:
Your going way to complicated by actually passing the variadic
arguments to the generator function. If you don't pass the
variadic arguments to the generator function its way simpler
and also works ;-)
http://dpaste.dzfl.pl/59e2547b
Thank you for your responses!
The following is a modified version of my original post code that
incorporates a bit from all the answers I received, and certainly
puts me farther along than I was:
http://dpaste.dzfl.pl/f7508d25
Taking Benjamin Thaut's suggestion to move the alias's into the
global scope, GrabBagT now has access to the types it needs to
know about, and my witchcraft abomination of a magic class works
as long as everything is available in the same file.
However.
My original goal, going back to how I want to use this in the
project I'm working on, is to define GrabBagT, and the associated
templates, in a different file, such that I need only import the
file and call:
auto magicObject = new GrabBagT!("MagicClass", SomeTypeAlias,
SomeOtherTypeAlias).MagicClass();
Which brings us back to the original problem, that passing in
aliases to instantiations of templates doesn't work, because the
type information is lost. I understand the fundamental issue you
folks were bringing up in your posts: GrabBagT cannot possibly
actually have access to the real types of the aliases it's
receiving, as those types aren't available in its scope (which is
why bringing the aliases originally defined within main() out
into the global scope makes things work).
But then this raises another fundamental issue, as I'm doing this
exact thing successfully (passing aliases of template
instantiations to other templates), where the only difference is
the receiving templates do not have variadic parameters, and I
throw the actual template parameter into the mixin itself. That
is to say:
If the template I am trying to instantiate IS NOT variadic, and I
pass in an alias of an instantiated template, then the receiving
template has all of the type information it needs. Example:
dpaste.dzfl.pl/6d618af9
If the template I am trying to instantiate IS variadic, and I
pass in a variadic list of aliases of instantiated templates,
then the receiving template appears unable to retrieve all of the
type information it needs out of each of the indexes of the
variadic parameter. We get close with this next example, but the
problem appears to be that it tries to create a static array of
the tuple T of length i, instead of indexing into it to get the
type (but if you provide an i greater than the actual length of
the tuple, it complains about going out of bounds of the tuple
length, meaning that it IS in fact aware that it's supposed to be
indexing into a type tuple): dpaste.dzfl.pl/ff8a5b9d
Given that the compilation error messages in the last DPaste
refer to the mixed in code after the class definition string is
generated and returned, the issue has to be in the way the type
tuple is treated, itself.
So, first, the template argument (variadic or otherwise) needs to
be part of the STRING that is constructed and passed back to the
mixin, so that it can then just naturally access GrabBagT's T
type tuple parameter. This is how the non-variadic DPaste example
works.
Second, the variadic version seems to fail because the type tuple
is not indexed correctly, to retrieve the type at that index,
because it instead appears to try to make a static array of the
whole tuple (which is odd because if you try to index the tuple
with an index beyond its length, it suddenly knows it's a type
tuple again).
And to be absolutely clear, the underlying goal is to generate a
class definition at runtime, which I can mix in and then
instantiate, that can contain an arbitrary list of data members
that are themselves generated at compile time by their own
templates. I have demonstrated that it is possible to do this
with a single arbitrary template instantiation in
dpaste.dzfl.pl/6d618af9 , but as soon as we try to do it with
type tuples, it chokes. I am not sure if this is a compiler bug
or I'm just out of my mind, but again, for the sake of academic
advancement, lets try to solve the problem in complete disregard
of whether we should.
If any part of my explanation of our current status on this
problem is unclear, I would be happy to explain in an alternate
way.
Thank you again!
