Are all macros evil?

Question

In my experience, not all macros have been evil. Along the course of my career, macros have been useful in a limited context. In MFC, message crackers provided a concise DSL-like description for message maps. Type-agnostic macros provided useful utility functions for a pre-template versions of C++, albeit dangerous.

However, I have seen many more cases where macros were used poorly. I recall one such occasion where I was helping a co-worker track down a GPF caused by an obscure function call. Offhand, I instructed them to simply examine the disassembly in the debugger to provide some more clues. To my surprise this revealed pages and pages of assembly code for this single function call. Further investigation reveled this “function” was simply a macro which called several other macros. As it turned out the source of the GPF was four macro levels deep, but was a huge headache to unravel.

It seems to me that macros are a thing of the past. Does anyone still use them for any new development? In light of the current language syntax for C++, are all macros now evil? Do other languages use macros and how do they deal with the pitfalls?

Answer 1

Macros are not evil. Like anything, if you abuse them, they will be evil and bite you. They are still state of the art for header guards, for example. And they have proven to be quite useful for repeating tasks for me.

Answer 2

Macros are not evil.

But Automake is.

Automake heavily uses macros, and everybody hates it.

The primary problem with macros imo, is in general use, they are almost impossible to debug.

Sure, if a macro language is designed right then it makes it easier, but I have yet to use a complicated macro language that didn't suck.

I've coded in povray, ( yes, coded ) which largely utilises a macro language, but the feature set is incredibly small, which limits the damage it can wield, and as far as its concerned, they're not really like macros, they're more like a really simple template language.

But that doesn't pass for "Complicated" ;)

Answer 3

In general, macros are to be avoided if possible. But I wouldn't go so far as to say that all macros are to be avoided. There are just some things that can't be done by the C++ language.

The biggest problem with macros is that they don't obey normal rules of C++. For example:

#define ADD(x) x += x

What happens when you do this:

 int i = 1;
 ADD(i++);

Of course this gets expanded to:

 int i = 1;
 i++ += i++;

which probably isn't what was intended. If you use an inline function, you would get:

 int i = 1;
 i += i;
 i++;

Which is probably more like what was expected.

Answer 4

I use macros frequently however I take care to undefine them once I'm finished. The main problem is Macros don't have namespacing so its very easy to clutter the Precompiler and have macro conflict which will be really hard to find if they do compile without warnings.

Say you define FOR_LOOP and someone else or a library you use also defined FOR_LOOP... now which one will get processed is not obvious without header tracking. This is why I define and undefine all my macros, so my library users don't have unpleasant surprises

Answer 5

I'll ignore macros that don't take parameters - as litb says, if you want to tell the preprocessor what code to process, such as in include guards, they're the business. For many other purposes, a constant does as well.

If you have an idea for a parameterized macro, but realise you can replace it with a function template, then do so. The same goes if you can replace it with a struct template, perhaps using a function as well.

If you can't replace it with templates (or, to be precise, if you can't figure out how to do so), then assess whether to use a macro, or just suck it up and write things out longhand each time.

The thing about macros is that you're mixing two languages (the preprocessor language with "proper" C++). This creates headaches, because the compiler only understands one of them at a time, and so will cheerfully allow function-style macros which behave totally unlike actual function calls, which they syntactically resemble at the point of use. But there are cases where it's worth it.

One example is the "verbose logging macro": it does something you can't do without the preprocessor or messy duplication:

#define LOG(x) (std::cout << "expression " #x " evaluates to " << (x) << "\n")

int x = 23;
LOG(23);
LOG(x);
LOG(x*x);

The same goes for writing macros that pass __FILE__ and __LINE__ into your real logging functions.

Another is the "define a macro and include a header" hack:

data.h:

ENTRY(foo,1)
ENTRY(bar,2)
ENTRY(baz,3)

enum.h:

enum THINGY {
     #define ENTRY(A,B) thingy_##A = (B),
     #include "data.h"
     #undef ENTRY
};

switch.cpp:

switch(something) {
    #define ENTRY(A,B) case B: handle_##A (); break;
    #include "data.h"
    #undef ENTRY
}

And so on - you can do "one thing for each line in data.h", for any value of "thing" that can be written as a macro.

Answer 6

Macros in C++ are not always evil, but usually something that you should avoid (like reinterpret_cast).

In lisp, macros are an incredibly powerful tool that are used extensively (definitely not evil). For a good rundown of what lisp macros are and why they're different from C/C++ macros, take a look at this page.

The Nature of Lisp

Answer 7

Macros in C and C++ are very hackish... you should tend to avoid them. They aren't evil, much in the same way goto isn't evil - sure, if you use it properly, it can be fine (and, in assembly, 'goto' is the only way to branch). But it's easy to use improperly, and then it will really bite you.

This is off-topic, but Scheme / Lisp macros, as someone else mentioned, are pretty incredible. It's unfair to call these both 'macros' as they really are different things. (That's why I say this is off-topic, as you asked about C++ macros).

Answer 8

The best reason for me is that macros are good built in tool for code generation in C/C++. Using them in cases where a function or template function can be used however is a bad idea.

Answer 9

Macros can be evil, but so can many other aspects of C/C++ when abused. You can often find a better solution than a macro, though. For example:

#define CONDITION 0
...
#if CONDITION
...
#endif

can in many cases be:

const bool CONDITION = false;
...
if (CONDITION)
{
    ...
}

Any good compiler will recognize that CONDITION is constant and will remove the dead code.

Another example:

#define MAX(a,b) ((a)>(b) ? (a) : (b))

is better replaced by:

template<typename T>
T Max(T a, T b)
{
    return a > b ? a : b;
}

Answer 10

Macros have some uses that can't be supplied by templates.

The # and ## come to mind. They can be used to generate good debugging messages by showing you the name of the variable and it's value.

something like this.

#define SHOW_VARIABLE(X) cout << "Variable " << #X << " <" << (X) << ">\n";

My rule of thumb is that if you can do it with a template, that is the way to go, otherwise be careful and do it with a macro.

Answer 11

For modern C++, macros should absolutely not be used as shorthand when inline functions would suffice. The tinyXml answer, for example, is probably an example of needless macro abuse.

However, macros are still somewhat useful for code generation. Consider using template traits where all of the native types should be defined by default. You might have some code like this:

template <typename T> struct my_traits {
    const static bool is_specialized = false;
    const static int type_id = 0;
};

Now you have to specialize for every supported type, but the text is nearly identical in all specializations:

template <> struct my_traits<bool> {
    const static bool is_specialized = true;
    const static int type_id = 1;
};
template <> struct my_traits<unsigned char> {
    const static bool is_specialized = true;
    const static int type_id = 2;
};

// and so on...

I would much rather see this code...

#define DECLARE_MY_TRAITS(TypeId, Type)      \
template <> struct my_traits<Type> {         \
    const static bool is_specialized = true; \
    const static int type_id = TypeId;       \
}
DECLARE_MY_TRAITS(1, bool);
DECLARE_MY_TRAITS(2, unsigned char);
// and so on...
#undef DECLARE_MY_TRAITS

It's definitely a niche use-case, but when it helps, it helps a lot. Still, most macros I run into are the "bad" kind, but those are generally easy enough to refactor.

Answer 12

I thought most macros were evil until I met "unlikely" and "likely" in the linux kernel. They have their place. As with anything, use wisely and they will treat you in kind.

Answer 13

Yes, all macros are evil primarily for two reasons. For one, you subvert the language's type system and ddefeat much of the compiler's ability to find mistakes in your code. So code that uses a lot of macros is more susceptible to having subtle defects that will take a lot of time to identify & fix. For another, by making extensive use of macros to generate code in places where templates or inline'd functions would be better suited for the task, you create your own little secret language within the C++ language that nobody but you understands and is very difficult to debug & maintain.

That said, sometimes macros are the lesser of two evils and still have to be used. The most common ones have been mentioned, but even then you should try to use them only where necesarry. Take for example the verbose logging function mentioned multiple times here. Most people write the function like this:

#define LOG(x) cout << __FILE__ << ":" << __LINE__ << " expression: " << x << endl;

The only thing you need to use the macro for in the above is to generate the FILE and LINE strings for the place where LOG() is actually invoked. A better implementation of this functionality takes the code that doesn't have to be in the macro and puts it in another construct, such as:

inline void Log(const char* file, const char* line, const char* expression)
{
  cout << file << ":" << line << " expression: " << x << endl;
}

#define LOG(x) Log(__FILE__, __LINE__, x);

Answer 14

C++ is lacking.

macros are one way to make it stronger albeit a very crappy one. a good approach instead would be to do code generation like with protobuf.

however, sometimes macros can be the lesser of evils. if you have to work with some other crappy code they can occasionally help you.

// (based on a true story)
// crap alert - C naming style in C++ and "proper accessors" will this a pain:
if (src_entry.ZugaVehicle_get_name_by_ref() != NULL)
  dst_entry.ZugaVehicle_set_name(src_entry.ZugaVehicle_get_name());
if (src_entry.ZugaVehicle_get_license_number_by_ref() != NULL)
  dst_entry.ZugaVehicle_set_license_number(src_entry.ZugaVehicle_get_license_number());
if (src_entry.ZugaVehicle_get_weight_kg_by_ref() != NULL)
  dst_entry.ZugaVehicle_set_weight_kg(src_entry.ZugaVehicle_get_weight_kg());
// ...

turns into

// crap alert - still crap but a little less..
// macro should have descriptive name so you won't have to need to parse it
#define COPY_IF_HAVE(X) if(src_entry.ZugaVehicle_get_##X##_by_ref() != NULL) dst_entry.ZugaVehicle_set_##X(src_entry.ZugaVehicle_get_##X());
COPY_IF_HAVE(name);
COPY_IF_HAVE(license_number);
COPY_IF_HAVE(weight_kg);
// ...
#undef COPY_IF_HAVE

both are ugly, and ideally you would never have to interface with code that forces crap on you.

btw, in linux you can use the "cpp" tool to see what the macros expand to.

Answer 15

Yes, macros are evil, for certain definitions of evil. That doesn't mean you should never use them, just that there are pitfalls and you should try to find a better way first.

Answer 16

At least BOOST_FOREACH is not evil :)

Answer 17

The only macros I use are:

• Header guards.
• Windows specific pre-compiled header macros (WINVER, _WIN32_WINNT, etc.).
• All-configuration /D macros (_CRT_SECURE_NO_WARNINGS, etc.).

All others have been replaced by functions or templates.

Answer 18

All macros are evil except multiple inclusion guards...

Check up the C++ FAQ if you don't believe me, and yes I truly believe this ;)