CODEWITHSUNDEEP
c++warningspreprocessorclang++
Jeremy Friesner
Jeremy Friesner

Reputation: 73209

#ifdef macros vs -Wpedantic and "extra" semicolons

My code-library has a header file that contains this bit of preprocessor magic:

#ifdef ENABLE_DEBUG_OBJECTS
# define DECLARE_DEBUG_OBJECT(v) DebugObject obj(v)
#else
# define DECLARE_DEBUG_OBJECT(v)
#endif

The idea is that in various classes in other header files, I can do this:

class MyClass
{
public:
   MyClass() {}

private:
   DECLARE_DEBUG_OBJECT(123);
};

... and if I've defined -DENABLE_DEBUG_OBJECTS in my Makefile, then MyClass will have a DebugObject in it as a private member variable, or if I didn't, it won't.

This works fine, except for one minor annoyance -- if I compile my code with clang's -Wpedantic flag, and without -DENABLE_DEBUG_OBJECTS present, I get lots of warnings about the "extra" semi-colon at in the private: section:

$ clang++ -Wpedantic ./test.cpp
./test.cpp:14:29: warning: extra ';' inside a class [-Wextra-semi]
DECLARE_DEBUG_OBJECT(123);

Now two obvious ways to avoid this would be to disable the extra-semicolons warning, or to put the semi-colon into the #define line instead of keeping it separate in the private: section of MyClass.

However, I'm feeling stubborn, and so I'd prefer to keep the semicolon separate (just for aesthetic reasons), and I'd also like to be able to enable -Wpedantic without seeing this error pop up all over the place.

So my question is: Is there some no-op token I can put into the non-ENABLE_DEBUG_OBJECTS branch of the above #ifdef that would convince clang++ to not complain about the semicolon, but otherwise be a no-op as far as the compiler is concerned?

Upvotes: 2

Views: 462

Answers (2)

MSalters
MSalters

Reputation: 180010

An alternative (works back to C++98) would be static const int v = 0. Since this is an integral constant expression, compilers usually don't need to allocate storage for it/ That makes it a true no-overhead no-op.

Upvotes: 1

Qaz
Qaz

Reputation: 61970

A trivial static assertion (static_assert(true, "");) isn't currently picked up for Clang warnings. That could change with future versions, however.

Upvotes: 1

Related Questions