Printable View
I don't think anybody's arguing that MACROS don't have their place, but in my experience misuse is more common than correct use. Most macros can be replaced with const variables, typedefs or templates to good effect, reaping the benefits of type safety and debugger friendliness.
When trying to solve a problem, #define is one of the last places you should look. Even so, macros have thier uses, as the examples pointed out in this thread.
Jeff
If macros are sooo baaad, then why do all compilers put hundreds of macros in their include files? And every 3d party library that I've seen to the same thing. Just take MSVC6 as an example. My god, there must be several thousand #defines's scattered throughout the include directory. Just a quick search in the include directory shows that 752 files contain the word #define at least once!
;)Code:#ifndef _MYHEADER_H_
#define _MYHEADER_H_
//header goes here
#endif // _MYHEADER_H_
And of course, Macros are very useful, since they allow you to maintain the "same" code for different targets. Like Unicode vs. non-Unicode, Debug vs Release etc.
I guess the places where macros should not be used are:
- for typedefs (especially those that don't depend on the target for the compilation)
- for constant PODs that are actually used. Typechecking might come in handy.
- instead of templates if templates would do the job just as well.
- instead of inline functions. It's hard to debug and very error-prone.
That is because many of those headers are 'C' headers, not C++ headers. For example <windows.h> and basically *any* API header is a 'C' header. Remember that 'C' programmers also use windows.h and const works differently for C than C++ The responsible thing to do is to use #define.Quote:
Originally posted by stober
If macros are sooo baaad, then why do all compilers put hundreds of macros in their include files? And every 3d party library that I've seen to the same thing. Just take MSVC6 as an example. My god, there must be several thousand #defines's scattered throughout the include directory. Just a quick search in the include directory shows that 752 files contain the word #define at least once!
This is why you see third-party libraries make their headers as generic (i.e. 'C'-like) as possible -- so as not to cause problems to the 'C' programmers out there who may be using their library. You will also notice that the good headers use the 'C' comment structure (/* */) instead of the // comment. Why? Again, because 'C' programmers and 'C' programs still exist, and usage of the // comment may be an error for the C compiler.
Regards,
Paul McKenzie
Paul, there is no C or C++ include file which doesn't also include a wrapper macro which I know of. Likewise there are many macros in VC++ which weren't in MSC way back in the day. The reason is that macro's can be changed at compile time and variables cannot, at least not without macros. Macro's provide compile time logic which variables simple can't. Macros can even be changed even from within MAKE files. These properties make macro's greater than variables even while they are less than in other respectsl. ... I will give you that macro's can be overused, and that the inherent weakness in a lack of type checking makes choosing macros on many tasks suspect.
But to say they can be replaced by const variables or protected class variables is just to stick one's head into the sand and to ignore that macro's compile time resolution gives macros an advantage over const variables which are versatile, advantageous and frankly standard in everything but the most trivial of tasks. To say using macro's is unprofessional ( as someone related second hand, not you ) is just to stand butt naked on one's desk and howl at the moon. It’s hard to take such a statement seriously... The only reasonable argument is in the degree.
True, but unfortunately sometimes those people sign your paychecks. :(Quote:
Anybody who would tell you that macro's are unprofessional is a person who doesn't understand what they're used for... such absolutism is a totem of mediocrity..
Luckily, I do not currently work for any of these people. :)
I don't think I'm disagreeing too much here. I'm just answering why some header files use #define instead of const.Quote:
Originally posted by JMS
Paul, there is no C or C++ include file which doesn't also include a wrapper macro which I know of. Likewise there are many macros in VC++ which weren't in MSC way back in the day. The reason is that macro's can be changed at compile time and variables cannot, at least not without macros. Macro's provide compile time logic which variables simple can't. Macros can even be changed even from within MAKE files. These properties make macro's greater than variables even while they are less than in other respectsl. ... I will give you that macro's can be overused, and that the inherent weakness in a lack of type checking makes choosing macros on many tasks suspect.
But to say they can be replaced by const variables or protected class variables is just to stick one's head into the sand and to ignore that macro's compile time resolution gives macros an advantage over const variables which are versatile, advantageous and frankly standard in everything but the most trivial of tasks. To say using macro's is unprofessional ( as someone related second hand, not you ) is just to stand butt naked on one's desk and howl at the moon. It’s hard to take such a statement seriously... The only reasonable argument is in the degree.
Backward compatibly with 'C' modules is one reason since const works differently for C than C++. I'm talking strictly about the "simple" #defines, which are probably most of the ones that stober came across when he searched the header files.
It's the same reason why many header files still use "typedef struct" instead of "struct" -- backward compatibility with 'C' modules.
Regards,
Paul McKenzie