[Insight-developers] RE: Complex vs f2c.h, "real" symbol conflicts in gcc 2.95

[Brad King]

Luis Wrote:
> Possible solutions are:
>
>   1) drop support for gcc 2.95   :-)
>
>   2) replace <complex> with vcl_complex
>
>   3) edit all f2c.h code and replace the 'real'
>      with a name less prone to collision.
>
>   4) create a native itk::Complex and do the right thing

I've investigated the possibility of fixing vcl_complex.h to avoid
putting the symbol "real" in the global namespace.  It turns out this is
not possible to implement without resorting to the
emulation/vcl_complex.h, which would not have the GCC 2.95 optimizations
in its complex implementation.

The reason is that we cannot define a macro "real" temporarily while
including the header to rename the symbol.  This is because the name
"real" is also used for a method name inside the complex template that
should not be vcl_real.  Even if we then derive from the std::complex<>
template and put the "real" method back it doesn't work because the
float, double, and long double versions of complex are specialized and
implemented in libstdc++.  Therefore the renamed method becomes an
unresolved symbol.

This is going to be a problem for option 4 also.

William A. Hoffman wrote:
> Is #4 really the right way?   Seems like we want to use the c++ type complex,
> much like we use std::vector we want std::complex.   We use std::vector all over
> the place in ITK, and itk::Vector is a different thing, not just a thin wrapper
> on std::vector.  Maybe the answer is to create sort of an itk version of vcl_complex,
> that goes by std::complex and is only used for this compiler.  Maybe a simple
> include file that does a namespace std { #include <complex> }  and make sure
> that file comes first in the include path. 

Putting namespace std {} around the inclusion of the header does not
work because in gcc 2.95 the "std" namespace just points back at the
global namespace.  This means the symbol conflict will still occur.  The
only solution of this kind sould be to rename the global function but 
not the method, which is hard as I explained above.

I think from an implementation point of view #3 is the unfortunate best 
choice.

-Brad