[Insight-developers] Explicit Instantiation Proposal

[Zachary Pincus]

A few thoughts -

(1) Are there plans for limited CMake control of what gets  
instantiated? E.g. defining some symbols INSTANTIATE_INT,  
INSTANTIATE_2D, or whatever, that the generic macros will key into  
with #ifdefs, etc? Or will filter developers just decide on their own  
which filters and which types ought to be explicitly instantiated?

(2) A request: it would be really nice for WrapITK if there was a way  
to exclude the .txx files from being parsed by gcc-xml. Specifically,  
a preprocessor symbol that *only* serves to be the gatekeeper to the  
txx files. Right now, it's ITK_MANUAL_INSTANTIATION (except for with  
itkVector, which I don't fully grok). It would be great if through  
all of this, there remained one symbol that does nothing but  
determine whether the .txx files are #included.

(3) There is another approach to the explicit template instantiation  
process that I have been thinking about. Now, I'm not sure it is a  
good idea, and it may even be overtly bad, but here goes.

In WrapITK, we have a bunch of little CMake files, one for each  
filter more or less, that in a fairly clear syntax describe the  
template types that that filter may be instantiated with. Then when  
we read through these files in the CMake stage, we take the union of  
the possible templates with the user-selected wrapping types, and  
generate CableSwig input files.

There's no reason that a similar process couldn't do what's needed  
for explicit template instantiation. CMake would read a file  
describing the filter and then write a .cxx file containing the  
instantiations, and write another header or something that has the  
'extern' or 'do_not_instantiate' lines. The cxx and header files  
could be written for each filter, or omnibus ones could be written  
for each library.

The bottom of any header could then look thus:
#ifdef EXPLICIT_INSTANCES
#include itkFooInstances.h // auto-generated by CMake
// (or #include itkCommonInstances.h if the omnibus approach was taken)
#endif
#include itkFoo.txx

And then to make the instantiations for ITKCommon, just compile the  
one or multiple cxx files (ITKCommonInstances.cxx or  
itkFooInstances.cxx/itkBarInstances.cxx/itk...) that CMake has  
generated.

Advantages of this approach:
   (1) Finer-grained control of what gets instantiated, and how
   (2) Less tricky macros
   (3) Explicit metadata about how filters should be instantiated is  
provided, which is useful for other things like wrappers.
   (4) A glance at the list of filters with corresponding cmake  
metadata files indicates which ones have been so described.
   (5) The CMake macros for declaring how a filter is to be  
instantiated are far easier than the preprocessor macros, because the  
latter is more powerful than the former.

Disadvantages:
   (1) More files floating around
   (2) Preprocessor trickery substituted for CMake trickery (I think  
this is a net gain, but hey)

So that's just a thought. Obviously it dovetails with WrapITK, but I  
think there are enough advantages from doing things through CMake  
that something along these lines is worth consideration.

Zach