[Insight-developers] Explicit Instantiation Proposal

[Zachary Pincus]

>> Now that the "code organization" section is up, I see that this  
>> will  remain possible. I was just asking if that was in fact the  
>> case. One  aside: right now setting ITK_MANUAL_INSTANTIATION (just  
>> for gcc-xml)  causes the wrappers to explode badly because of  
>> something in  itkVector.h and its use of the new template macros.
>
> Please send me the error message produced.  GCC-XML should have no  
> trouble swallowing the current sources whether or not  
> ITK_MANUAL_INSTANTIATION is defined...as long as  
> ITK_EXPLICIT_INSTANTIATION is not enabled.

I'll do that in a bit, off-list.

> I thought your "metadata" referred to the names to use in the  
> wrapped languages for the instantiations.  These should match the  
> explicit instantiation names put in the Templates namespace.   
> Instead you are talking about treating all the information  
> currently encoded in the per-template instantiation macros (such as  
> ITK_TEMPLATE_Vector) as metadata encoded in CMake code.  See below.

Yep. Sorry about the imprecision in my language!

>>>>   (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.
>>>
>>> The macro-based instantiation design complements a CMake-based   
>>> instantiation generator.
>>>
>>> Generating instantiations with CMake has been the idea all along.
>> Then why spend all of this time developing fairly hairy  
>> preprocessor  macros, and then having those macros controlled by  
>> symbols that CMake  may define to select which instances to  
>> instantiate, when you could  do the logic more cleanly within  
>> CMake, and have CMake write out  exactly the instantiation files  
>> and headers you need at configure time?
>
> I was trying to encode the "metadata" to which you refer in a macro  
> defined in the header so that the CMake code did not have to see it.
>
> This is clearly the main point of discussion:
>
>   - how/where should we put this information?
>   - what exactly does it contain?

Well-put.

Now, WrapITK needs to maintain three pieces of information about a  
given template instantiation: (1) the class name (e.g.  
itk::ImageFileReader), (2) the set of template parameters (e.g.  
itk::Image<float, 2> ) and (3) what the scripting-language-safe  
"mangled name" of that instantiation should be (e.g.  
itkImportImageFilterIF2).

 From that information, we can easily generate the cable input files.

I suspect that for explicit instantiations, only the first two are  
necessary. So a "itkImageFileReader.cmake" file containing:

TEMPLATE_CLASS("itk::ImageFileReader")
   TEMPLATE("itk::Image<float, 2>")
   TEMPLATE("itk::Image<float, 3>")
...
   TEMPLATE_FUNCTION("std::ostream& operator<<(std::ostream& const  
@TEMPLATE@)")
...
END_TEMPLATE_CLASS()

should, I think, encode sufficient information to generate all of the  
necessary cxx and header files, with appropriate macro definitions  
that don't seem like they would be too complex.

Now, if CMake was keeping a list of the selected image types that had  
been templated (a good idea) this could be:

TEMPLATE_CLASS("itk::ImageFileReader")
   IMAGE_TEMPLATES(1)
...
   TEMPLATE_FUNCTION("std::ostream& operator<<(std::ostream& const  
@TEMPLATE@)")
...
END_TEMPLATE_CLASS()

Which would tell cmake to call the TEMPLATE macro on all of the known  
image types, with just one image template parameter. IMAGE_TEMPLATES 
(2) would be useful for image to image filters.

Anyhow, the more I think on this, the more I think that it might be  
difficult to make the "template type information" generic enough to  
be of direct utility to WrapITK or other similar endeavors, while  
still specific enough to deal with the corner cases of the explicit  
instantiations.

So really I guess all I'm floating here is an alternate approach to  
driving the template instantiations through CMake, in a fashion  
similar to how we've done things with WrapITK. I'd be happy to help  
with this approach if you so choose, but ultimately it's probably a  
matter of preference. I happen to think it might wind up being a bit  
more clear and maintainable if done via CMake (cf. hit by bus), but  
it's probably close to a push really.

>> Otherwise, I agree that having information in two separate files  
>> is  more of a pain than having it in one. In the context of a  
>> global  reduction in C-preprocessor pain, and in pain for outside  
>> folk who  could make use of some explicit and easily-parsed  
>> information about  what sort of template parameters a given class  
>> expects, it might  still be a win...
>
> We could also put it in the .h file in the form of a comment that  
> can be easily parsed by CMake code or some other tool.

Agreed. In any case this isn't a bad idea.


Zach