I missed an extremely critical point. The working example with
the single arbitrary template instantiation as a data member of
the generated class, http://dpaste.dzfl.pl/6d618af9 , has the
template instantiation aliases inside of main, meaning the alias
is NOT within the scope of GrabBagT, but it is able to get all of
the type information it needs from the alias being passed in.
Which reaffirms to me that the problem is not about whether
GrabBagT needs to be able to see what the alias refers to
(clearly it can figure it out), but that once these aliases are
wrapped up into a tuple passed into the variadic version of the
template, it stops being able to figure it out. Either the syntax
I'm using is wrong, there is a bug in the compiler, or for some
reason this extremely specific scenario isn't allowed.
In any case, example code that demonstrates the principle we are
trying to achieve as working should be able to call
magicObject.printSelf() and show that each of its arbitrary data
members can call their own printSelf() methods successfully, as
with the http://dpaste.dzfl.pl/6d618af9 example, but with an
arbitrary list of instantiated templates, instead of just the one.
Brain buster, this one.
