Why is #define not properly defined in child classes? - c++

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.

Answer 1

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)

Answer 2

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.