vendredi 10 octobre 2014

Why sometimes I really hate MACROS



I have sometimes a mixed feeling about MACROS, but today I found 2 reason to hate them a bit more than I like them!

 

I fact I work with a library and I wanted to define a simple C++ mapping table to translate one on that library enum into other value (as int), so I wrote:

static std::map<LibName::Level, int> LibLevelToExternalLevel_Map = boost::assign::map_list_of(LibName::INFO, 40000)(LibName::TRACE, 30000)(LibName::WARNING, 60000)(LibName::CONTROL, 40000/*map on INFO*/)(LibName::ERROR, 70000);

Note that modern C++ provide the initializer list but I’m still in the old age, using C++9… the shame on me !


And to get back on my topic, as I compiled that code, one of my compiler started to complain. From GCC POV that code was ok but from VC98.

(380) : error C2589: 'constant' : illegal token on right side of '::'

As often in that case, you can suspect 2 things:


  • compiler bug
  • preprocessor bug

I try to find which “LibName::XXXX” label caused the issue and I found that ERROR was the root of the problem….. And after more investigation I found that a windows.h file was include at some point in the .h tree I used for that cpp file.


You may be not aware, but if you include <windows.h> a macro ERROR will be define and it was the root of my issue. A naming collision…. And it’s not the 1st time I had collision in that cpp file. The lib I use also has a class with an API (public function member) call GetMessage, but to build under windows I have to un define a macro for a while….

#ifdef WIN32
#ifdef _UNICODE
#define GetMessage   GetMessageW
#else
#define GetMessage   GetMessageA
#endif
#endif

So to conclude and keep in mind a good rules to prevent that kind of naming conflict or collision, I would just advice follow a simple convention no ‘full’ uppercase in identifier name (function, variable, enum, etc….)  see google coding style

Aucun commentaire :

Enregistrer un commentaire