All Compilers are equal!
but some are more equal than others...

This page provides some of the painful facts about how much particular compilers actually support the C++ ISO standard. The facts in this page have been gathered after long programming and debugging sessions that culminate with the realization that you can not fully trust any compiler.

• Borland bcc 5.5
  
  
  • Not enums in templates
    
    One of the most salient features of Borland is the lack of support for enums as numeric arguments for templates.
    
    
  • Exceptions in division by zero
    
    The second salient feature is the fact that Borland throws exceptions when it encounters divisions by zero. This is actually a nice feature since it reacts to real problems in the code.
    
    
  • Limitation for Linking large libraries
    
    Borland linker has a low threshold for the size of libraries it can link. The consequence of this fact is that ITK cannot be built for Debug with this compiler because the linker will not be able to manage the size of the libraries. It is recommended that you build for Release with Debug Information (RelDebInfo) when you use this compiler.
    
    
  
  
  
• GCC
  
  Despite the fact that GCC is probably the compiler that best implements the C++ standard, there are still some issues that may be confronted with it.
  
  
  • GCC 3.2 : Dont use these flags
    
    The following combination of flags is known to produce run-time failures when used for compiling ITK: "-O3 -pipe".
    However, the following flags work ok with ITK code: "-O3 -march=pentium4 -pipe" Additional information on this problem can be found at Gcc 3.2 changes
    
    
  • GCC 3.3 : General
    
    The Following link lists Changes, Features and Fixes in gcc 3.3 Gcc 3.3 changes
    
    
  • GCC 3.4 : General
    
    The Following link lists Changes, Features and Fixes in gcc 3.4 Gcc 3.4 changes
    
    
  
  
  
• Visual Studio 6.0
  
  Don't even think about using Visual Studio if you haven't installed its service pack 6. You can download the service pack for free from the following link Service Pack 6
  
  
  • No partial specialization
    
    This is the main failure of Visual Studio 6.0, its lack of support for partial specialization. This compiler is responsible for restricting ITK from taking advantage of this nice feature of Generic Programming. Many architectural characteristics of ITK would have been designed differently should partial specialization of template being available. In particular the toolkit would not have needed to have separate instantiations of filters for Scalar images and Vector images.
    
    
  • Marking .txx files as compilable
    
    This is rather a user configuration mistake, but given that it is so common, it is mentioned here. Visual Studio allows to define what types of files should be compiled. It is a common mistake from users to mark the .txx files as being compilable. However, these files should only be compiled when included in .cxx files. When the compiler attemps to process .txx files directly a large number of error are produced.
    
    
  • No support for the "typename" keyword
    
    Visual Studio 6.0 simply ignore the typename keyword when it finds it. It does not require this keyword to be present in the cases defined by the C++ standards. This is today the most common source of multi-platform compatibility issues in ITK. When developers test their code using Visual Studio 6.0 and commit it they usually find that a large number of typenames are missing.
  
  
  
• Visual Studio 7.0
  
  
  • ICE with fstreams
    
    Internal Compiler Error have been found when std::ifstream or std::ofstream classes are uses as arguments of methods in templated classes. These ICE are usually solved by simply adding typedefs for these classes and using the newly defined types in the argument declaration of the methods.
    
    
  • ICE with #include order
    
    This compiler is also prone to produce ICE in the Header test methods in ITK. These ICE are usually solved by just changind the order in which the #include are made.
    
    
• IRIX
  
  
  • typedef are not inherited
    
    This is actually a good feature since it matches the C++ specification. However this compiler is the only one that actually adheres to the rule. It is therefore common to find code that compiles with any other compiler but fails with IRIX because the developer is using types that were defined in the superclass and not re-typedef in derived classes.
    
    
  • Overload of math functions
    
    The IRIX compilers provides overloaded versions of basic mathematical functions such as abs, fabs, sin, cos. Since the compiler is allowed to do implicit casting, it usually find itself confused as to what casting path to take. It is therefore recommended to explicitly set the types of the variables passed to basic mathematical functions.
    
    
  • STL
    
    The IRIX compilers has a particular implementation of the Standard Template Library (STL) in some cases have been necessary to install a local copy of the STL to make it work correctly with ITK.
    
    
  
  
  
• Sun native compiler
  
  ITK supports the CC Sun native compiler version 5.6.