[Insight-developers] ITK_EXPORT and the Dark side of the Force...

Luis Ibanez ibanez@choroid.cs.unc.edu
Wed, 2 May 2001 13:00:37 -0400 (EDT)


Hi

After several days of debugging and existentialist crisis
the following problem have been cleared.

In our beloved file  Code/Common/itkWin32Header.h  we have
the following declaration for the symbol ITK_EXPORT:



#if defined(_WIN32) || defined(WIN32)
# ifndef ITKSTATIC
#  ifdef  ITKDLL
#   define ITK_EXPORT  __declspec( dllexport )
#  else
#   define ITK_EXPORT  __declspec( dllexport )
#  endif
# else
#  define ITK_EXPORT
# endif // ITKSTATIC
#else
// Now for the UNIX stuff
#define ITK_EXPORT

#endif



Currently the symbols ITKSTATIC and ITKDLL are not
being defined. So ITK_EXPORT is being defined as
__declspec( dllexport ).  Unfortunately it seems
that a number of files containing the ITK_EXPORT
don't have itkWin32Header among their visible
includes.  The consequence is that in some parts
the symbol ITK_EXPORT is going just in blank.

The conflict with this situation arises when a
base class A do have ITK_EXPORT == __declspec(dllexport)
and some other class B deriving from A, have ITK_EXPORT
in blank.  Virtual functions declared in A have a
particular calling sequence, while the corresponding
functions on B use a different one.

The warning that protests about this situation is
now being disabled in the same file itkWin32Header.
(Warning 4251).  The confict only appear at running
time when a virtual function (in the A->B case) is
called, the stack end up in an inconsistent state,
and an exception is thrown.



--


Here are some options to get around this problem:


1) Define ITKSTATIC in a CMakeList.txt file,
   given that we are now only creating static
   libraries.


2) Remove the __declspec(dllexport) in the else
   part of the ifdef ITKDLL, so when ITKDLL is NOT
   defined (our current case), ITK_EXPORT will be
   blank everywhere.


3) Figure out a way to ensure that all the files
   that contain a ITK_EXPORT include directly or
   indirectly itkWin32Header.h
   It is not the case right now.


4) Remove the line disabling the warning 4251.



---

(1) and (2) should go together
(4) should in principle help with (3).




I would suggest to do (1) and (2) first,
which are quite easy, and maybe later do
(3) and (4), to cover all the combinations.




Any ideas ?







Luis