Why is #define not properly defined in child classes?

Question

I have a define in the base classes header file. Using the define in a derived class is not possible:

Plugin.h

#ifndef PLUGIN_H
#define PLUGIN_H

#include "../config.h"

#ifdef DEBUG
#define DEBUG_PLUGIN(...) ets_printf( __VA_ARGS__ )
#else
#define DEBUG_PLUGIN(...)
#endif


class Plugin {
public:
  Plugin();
  ...

SimplePlugin.h

#ifndef SIMPLE_PLUGIN_H
#define SIMPLE_PLUGIN_H

#include "Plugin.h"

class SimplePlugin : public Plugin {
public:
  SimplePlugin();
  ...

SimplePlugin.cpp

#include "SimplePlugin.h"

SimplePlugin::SimplePlugin() : _devices() {
  DEBUG_PLUGIN("[SimplePlugin]\n");     // <-- not printed
}

config.h has DEBUG defined. Could you highlight the preprocessor magic?

UPDATE

The comments got me on the right track. Macro expansion does of course not depend on class hierarchy, in fact not on the compiler at all but on the preprocessor. The macro is defined, expanded by preprocessor an executes, otherwise we would see compile errors.

It finally turned out that the Arduino/esp8266 ets_printf function needs additional hardware configuration or it will only work unreliably. That unreliable behaviour made it look like as if it was only called depending on location in the file/class hierarchy.

Macro's behavior has nothing to do with classes and derivation. However, your header file inclusion structure looks fine, meaning that most likely the macro works and works exactly as it should. If something is "not printed" in your case, preprocessor and the macro are not to blame for that. — AnT stands with Russia, Feb 04 '16 at 20:27
When do you expect that to get printed? And what is `ets_printf`? That's not a standard function. Where is it supposed to print? Are you sure? — Jonathan Wakely, Feb 04 '16 at 20:29
If a amacro weren't defined, you'd get compilation error, not missing output from running executable. — el.pescado - нет войне, Feb 04 '16 at 20:35
The issue is likely somewhere in `config.h`, since the problem seems to be that `DEBUG` isn't defined by the time the compiler gets to `DEBUG_PLUGIN`'s definition in `Plugin.h`. I tested it in TutorialsPoint's online compiler with the same file setup as your question, and it worked. (See http://goo.gl/a8MtrF , although you may need to `g++ main.cpp SimplePlugin.cpp` before you can run `a.out`.) — Justin Time - Reinstate Monica, Feb 04 '16 at 20:48

score 3 · Answer 1 · edited May 23 '17 at 12:07

Yes, you should read much more about the C/C++ preprocessor (both C & C++ share the same preprocessor, with some differences in predefined macros). It is operating textually only. It has no notion of types (e.g. class), or of scope.

You could get the preprocessed form of SimplePlugin.cpp using a command line like:

g++ -C -E SimplePlugin.cpp > SimplePlugin.ii

^{(you could have to add some additional -Dsymbol and -Idirectory before the -C, exactly as in your compilation command)}

Then, look into the generated SimplePlugin.ii file (the preprocessed form from SimplePlugin.cpp...) with your editor or pager.

You might even remove the line information (emitted by the preprocessor in lines starting with #) with

    g++ -C -E SimplePlugin.cpp | grep -v '^#' > SimplePlugin.nolines.ii

and then you could run g++ -c -Wall SimplePlugin.nolines.ii, the diagnostics would refer to the preprocessed file SimplePlugin.nolines.ii, not the original unpreprocessed SimplePlugin.cpp

Read also the documentation of GNU cpp

^{(I am guessing you use GCC; please adapt my answer to your compiler suite; I am even guessing that your bug might be unrelated to preprocessing)}

C and C++ preprocessors have much in common but are not actually identical. There is plenty of discussion about, for example http://stackoverflow.com/questions/5085533/is-a-c-preprocessor-identical-to-a-c-preprocessor — Peter, Feb 04 '16 at 21:38

Peter · Accepted Answer · 2016-02-05T10:19:41.237

Obvious possible explanations would be

ets_printf() - which is non-standard, and you have not described - does not work as you believe. For example, it could itself be a macro that is defined to do nothing if DEBUG is defined.
DEBUG is not actually defined in your config.h. A typo somewhere could easily mean some other macro is being defined, rather than the one you believe.
The header might actually be defining DEBUG but the preprocessor subsequently encounters an #undef DEBUG. That may be in the same header, a different header, or even in your including source file.

The problem is unlikely to have anything to do with definitions of classes or constructor. The preprocessor does not follow scoping rules.

Why is #define not properly defined in child classes?

2 Answers2