[Insight-developers] Explicit Instantiation Proposal

Wed Apr 26 18:57:19 EDT 2006

I really think we should write the most common use case here, and we'll have a 
better idea of what should be done, and at which layer.
Please try to complete/rewrite[1] what I wrote in my previous mail

Gaetan

[1] still my poor english problem

On Wednesday 26 April 2006 23:38, Zachary Pincus wrote:
> >> 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
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://www.itk.org/mailman/private/insight-developers/attachments/20060427/100fe87e/attachment.pgp