[Insight-users] Explicit Instantiation question

[Brad King]

Rupert Brooks wrote:
> I found this document
> (http://www.itk.org/Wiki/Proposals:Explicit_Instantiation) but after
> reading it i must confess i was still confused.  What i really wanted
> to know was how, as a user, im supposed to manage this issue now.
> After some difficulty, i got it to work by switching on
> ITK_MANUAL_INSTANTIATION before including the relevant files.
> Pseudocode follows.

There is an option provided in the CMake interface called
ITK_EXPLICIT_INSTANTIATION that causes a bunch of instantiations to be
done for you this way.  You have to look in the 'advanced' options list
to see it.  Turning it on provides many instantiations in the ITK
libraries themselves.

> Overall, it works, and i sped up my build by about a factor of 3,
> which is what i wanted.  But i still have some problems, and i have a
> gut feeling im doing it the "wrong way".  I wondered if people could
> tell me what the "RIGHT" way to do this is.  Possibly some of these
> problems are bugs, in which case i  should report them.  But im not
> sure.

You're approach is basically correct for doing this in an outside
project.  ITK_MANUAL_INSTANTIATION was meant for exactly that.

> 1. Not only did i have to explicitly instantiate all the classes that
> i actually use, but i had to instantiate their parents in some cases.
> Eventually, i just kept building, and whatever symbols the linker
> couldnt find, i would manually instantiate.

This is expected.

> 2. After I have used ITK_MANUAL_INSTANTIATION to block the inclusion
> of txx files i have to manually include them for templated classes i
> do want to implicitly include.  Again, a minor annoyance, but makes me
> wonder if im doing this wrong.

This is expected.

> 3. For at least one class, itkPoint.h, probably more, this approach
> does not work because the helper functions to allow things like
> std::cout << mypoint are not explicitly instantiated.  I made a few
> unsuccessful attempts to explicitly instantiate them by using them in
> dummy functions in my explicit.cxx file, but it didnt work.

The non-members need to have their own explicit instantiation lines.  In
the case of itkPoint.h the ITK_EXPLICIT_INSTANTIATION feature exports a
few point type instantiations for you from ITKCommon.  Many types
provide macros to help create all the necessary instantiations.  You can
see them at the bottom of the header files (see itkPoint.h).  The macros
in the headers are not meant to be called directly.  Their design is
documented in that Wiki entry you mentioned.

If you turn on ITK_EXPLICIT_INSTANTIATION you will find a bunch of
directories like Code/Common/Templates in the build tree.  The files in
these directory contain appropriate macro invocations.  They cause
instantiations to be done explicitly inside libraries and then
DLL-exported from them.  When a user includes the header they will see
those instantations as DLL-imported (or at least marked as "extern"
explicit instantiations to prevent implicit instantiation...a
platform-specific extension available on most platforms).

> 4. Certain classes dont seem to have all the members available for
> instantiation.  On Visual C++ this gives a warning, on gcc 4, it is
> ignored, and on gcc 3 it is a build-stopping error.  Whats very wierd
> is i dont seem to be getting the same missing functions on gcc3 and
> VC++.  Are these missing members a bug, or is there some trick to
> instantiateing the classes?  I'm still investigating this one on gcc
> 3.  Example warning message from VC++ follows.

The missing methods are purposely not implemented.  They are the copy
constructor and assignment operator of all classes in the
itk::LightObject hierarchy.  See itkLightObject.h:

  LightObject(const Self&); //purposely not implemented
  void operator=(const Self&); //purposely not implemented

There is code setup in itkMacro.h to block these warnings for Visual
Studio inside the .cxx files created by the ITK_EXPLICIT_INSTANTIATION
feature:

#if ITK_TEMPLATE_CXX
//...
# if defined(_MSC_VER)
#  pragma warning (disable: 4275) /* non dll-interface base */
#  pragma warning (disable: 4661) /* no definition available */
# endif
#endif

I have never seen warnings or errors from any version of GCC.

-Brad