Best Coding Practices

This page should be expanded to include some best coding practices.

Changes to run with Microsoft Visual C++

1. The GNU pre-processor directive #warning is not recognized. At least MSVC++ and Intel Compiler (ICC) recognizes "#pragma message" for the same functionality. We can use this pragma as default, hoping that other compilers informs the message to the user, or even stop with error if it is not recognized. But there is a change that this unknown #pragma is just ignored... Note that it is shown only in warning level 3 in MSVC++.

  1. # ifdef __GNUC__
  2. #  warning "the messsage goes here"
  3. # else
  4. #  pragma message("the message goes here")
  5. # endif

2. Support for variatic macros was introduced in Visual C++ 2005. The C99 standard is supported, meaning the ellipses argument should be unnamed (a name before the ... token is not supported) and referred to as __VA_ARGS__ in the body of the macro. Both GCC and MSVC++ allows the ellipses match no argument (although the standard forbids it), but GCC needs the operator ## before the __VA_ARGS__ to swallow a previous comma if this happens. Example of a change:

  1. // OLD code
  2. #define GB_PARAM(name,type,value...)  name = gb_param<type>(#name,##value);
  3.  
  4. // NEW code
  5. #define GB_PARAM(name,type,...)  name = gb_param<type>(#name,##__VA_ARGS__);           \

3. #include <sstream> in files that use std::stringstream. For some reason, GCC don't complain about that, but MSVC++ does complain about undefined class 'std::basic_stringstream<_Elem,_Traits,_Alloc>'.

  1. #include <sstream>
  2. std::stringstream foo;

4. All code needs to be compiled in all target compilers, to avoid clash in symbol names from user code and library code. That happened with the symbol ATOM used in GreenBus. That name is also used in a MSVC++ base library. The symbols that clash need to be renamed.

Posted July 2nd, 2008 by MarcusBartholomeu