July 01, 2002
C and C++: Siblings
July 2002/C and C++: Siblings/Sidebar
Macros
C and C++ programmers view macros very differently. The difference is so great that it can be considered philosophical. C++ programmers typically avoid macros wherever possible, preferring facilities that obey type and scope rules. In most cases, C programmers dont have such alternatives and use macros. For example, a C++ programmer might write something like:
const int mx = 7;
template<class T> inline T abs(T a)
{ return (a<0)?-a:a; }
namespace N {
void f(int i) { /* ... */ }
};
class X {
public:
X(int);
~X();
// ...
};
A C programmer facing a similar task might write something like:
#define MX 7
#define ABS(a) (((a)<0)?-(a):(a))
void N_f(int i) { /* ... */ }
struct X { /* ... */ };
void init_X(struct X *p, int i);
void cleanup_X(struct X *p);
At the core of many C++ programmers distrust of macros lies the fact
that macros transform the program text before tools such as compilers see
it. Because macro substitution follows rules that dont involve scope
or semantics, surprises can result. Namespaces, class scopes, and function
scopes provide no protection against a macro. Eliminating the use of macros
to express ideas in code has been a constant aim of C++ (see Chapter 18 of
[8]). A C++ programmer tends to view a solution
involving a macro with suspicion and, at best, as a lesser evil. On the other
hand, a C programmer often views that same solution as natural and often as
elegant. Both programmers are right in their respective languages, and this
is a source of some misunderstanding. Any solution to a compatibility problem
that involves a macro is automatically considered suspect by many C++ programmers.
Thus, any use of a macro in the Standard becomes a potential incompatibility
as the C++ community looks for alternative solutions to avoid its use. The
only macro found in the C++ Standard (besides those inherited from C) is __cplusplus.
Previous Page |
1
|
2
|
3
|
4
|
5
|
6
Next Page