[Insight-developers] Explicit Instantiation Proposal

[Miller, James V (GE, Research)]

I like the fact that every template does not need be instantiated explictly.

We could stop the instantiations at the concrete filter level if we wanted.

However, I am sure that after the first pass of putting in explicit instantiation,
there will be other instantiations that we'll want to add and some are going to
require new macros.  The simpler we can make the macro writing the more likely 
we'll survive the hit by the bus test.

Jim


-----Original Message-----
From: insight-developers-bounces+millerjv=crd.ge.com at itk.org
[mailto:insight-developers-bounces+millerjv=crd.ge.com at itk.org]On Behalf
Of Brad King
Sent: Wednesday, April 26, 2006 10:21 AM
To: Miller, James V (GE, Research)
Cc: Julien Jomier; Zachary Pincus; Insight Developers
Subject: Re: [Insight-developers] Explicit Instantiation Proposal


Simon Warfield wrote:
> Miller, James V (GE, Research) wrote:
>> Thanks for putting together this page.  I was hanging with it until we 
>> got
>> to the handling of multiple template arguments.  My concern is whether 
>> developers
>> are going to be able to write the macros like
>>
>> #define ITK_TEMPLATE_Vector(_, EXPORT, T, D) namespace itk { \     
>> (2(class EXPORT Vector< T,D >)) \
>>     (1(EXPORT std::ostream& operator<<(std::ostream&, \
>>                                        const Vector< T,D >&))) \
>>     (1(EXPORT std::istream& operator>>(std::istream&, \
>>                                        Vector< T,D >&))) \     }
> 
> Look at it from the point of view of a new student learning medical 
> imaging, and considering to use ITK.
> Weighing the pros and cons of sophisticated C++, with templates and 
> image processing of N dimensional arbitrary type voxel data.
> 
> All the student needs to do is work with macros like that, and it will 
> save the compiler a lot of time and a lot of disk space too!

I have a few answers for this:

1.) There is no reason this student would have to deal with such macros. 
  The design does not have to be used for every template.  We can pick 
and choose templates for which explicit instantiation support is 
desired.  Only templates that are commonly used and thus likely to have 
repeat instantiations need to be converted.  Also, the cost of not doing 
this for a template is only compile time and disk space.

2.) Saving the compiler time also saves the student time when it comes 
to the edit/build/test cycle.

3.) The vxl community has been using instantiation macros similar to 
this for years.  We even have some of them in ITK because we use vnl.

>> When we get to this level of complexity are we better off simply 
>> writing out
>> the template instantition?  Granted, it would be awfully repetitive 
>> (having to put in similar lines for each instantiation) but more 
>> tractable for a developer.
>>
>> I am all for macros for simplifying the export/import mayhem. So the 
>> question is
>> whether this
>> // Bottom of itkFoo.h namespace itk { #if (...compiler supports extern 
>> instantiation...)    extern template class ITKCommon_EXPORT Foo<int>; 
>> #elif (...compiler supports do_not_instantiate...) # pragma 
>> do_not_instantiate class ITKCommon_EXPORT Foo<int> #endif }
>>
>> could be simplified to something like
>>
>> TEMPLATE_EXPORT(ITKCommon) Foo<int>;
>>
>> so the Foo<int> or Vector<double, 3> is not passed into the macro.

This syntax has several problems:

1.) It will not support the do_not_instantiate pragma on the SGI.
2.) It does not allow the line to be completely removed when explicit 
instantiation is not used.
3.) There is also nothing tying together all the declarations associated 
with the instantiation, so in the case of Vector one could easily leave 
off the streaming operator for one instantiation but not another.
4.) The line is not generated by a macro so we would need complicated 
include-file tricks to make it show up in all the places it is needed.

-Brad
_______________________________________________
Insight-developers mailing list
Insight-developers at itk.org
http://www.itk.org/mailman/listinfo/insight-developers