[Insight-developers] Explicit Instantiation Proposal

[Brad King]

Gaetan Lehmann wrote:
> Unless I'm completely wrong, we will have to write the tricky macros only for 
> a few classes - the ones which require special things like the stream stuff - 
> so it doesn't look very problematic. Or I have missed something ?

They would be written for any template for which we want to enable 
explicit instantiation via this mechanism.  They just won't look quite 
as ugly without streaming operators in them.

> The explicit instantiation to include some code in libITKCommon seems clear 
> for me: some very often used template instantiation are selected and hard 
> coded in the itk code. It would avoid lot of work for the compiler, and would 
> highly shorten the compilation time. In that case, there is no need for 
> advanced template parameter selection (like in WrapITK) - everything is hard 
> coded.

This is the current situation with my prototype that is checked in. 
Only a few basic classes are done.  Note that this is not enabled unless 
ITK_EXPLICIT_INSTANTIATION is turned on.

> Use it for the wrappers seems quite clear too. We build some libs which 
> contain the code of the instantiations selected by the user and link the 
> language specific part to those libs. We will gain lot of compilation time 
> and total executable size. The code to select the instantiation doesn't need 
> to be part ITK, it can be located in the application (WrapITK) (tell me if 
> that's false).

Yes, and the same instantiation libraries can be shared across multiple 
languages.

> Using it for building the tests is less clear for me. How the instantions will 
> be selected ?

This would be a manual process to identify instantiations needed for the 
tests.  It amounts to building the testing tree with 
ITK_MANUAL_INSTANTIATION defined to make sure nothing is implicitly 
instantiated in the tests.  Then we would add explicit instantiations 
until the tests built.  Many of the tests build the same template 
instantiations over and over (like itk::Image<>).  Sharing them through 
explicit instantiations should shorten the build time and test tree size 
alot.

There is no real reason to do this testing tree stuff except for 
completeness.  Most of the benefit would be achieved by doing this for a 
few core class templates.

> Finally, how the final user will use this stuff, for all the instantiations 
> which will not be in libITKCommon ?

Users can continue to write code as they do now.  Whether an 
instantiation is imported from ITKCommon or generated implicitly by 
their compiler does not matter to them.

-Brad