It is bad style. So ok .
It is bad style. So ok .
Woop?
It's more than bad style. And macros do cause problems, even with experienced programmers. Microsoft added max and min macros to their windows header, and the C++ standards committee added max and min functions to the algorithm header. They cannot co-exist because of the deficiencies of macros.
http://www.parashift.com/c++-faq-lit...s.html#faq-9.5
incredibly the latest VC++ versions are getting standard compliant, so probably those macros will disapear in about 2/3 years
Originally Posted by prog-bmanthis can also be bad stlye.Code:float x; int i = *(int*)&x;
It all up to the programmers responsability. There's nothing wrong with well used and identified macros.
I doubt it in this case. The macros are in a non-standard header.Originally Posted by xErath
It also yields unspecified behaviour. While unspecified behaviour is not evil, it does mean the result is compiler dependent. If a style guide is concerned with portability (e.g. achieving the same results regardless of compiler), I suppose it might describe such tricks might be described as bad behaviour.Originally Posted by xErath
Depends on your viewpoint.Originally Posted by xErath
Macros, if misused, can be extremely dangerous, as they do text substitution that can make innocent looking code do something it doesn't appear to. Unintended misuse is probably the most dangerous: leaving a trap for some other programmer to encounter and get confused by is probably rarely a good idea. If you think about it, the problem that started this thread is an example can be viewed as an example of unintended misuse.
Technically, there are VERY few things that can be achieved with macros for which C++ does not provide safe alternatives. The only examples where one absolutely can't live without the preprocessor are with #include'ing headers, ability to define include guards and (arguably) macros such as __LINE__ and __FILE__.