Gotcha #26: #define Pseudofunctions

In C, #define is often used to define pseudofunctions, where the efficiency of avoiding the cost of a function call is considered more important than safety:

#define repeated(b, m) (b & m & (b & m)-1) 

Of course, all the usual caveats apply with respect to any use of the preprocessor. In particular, the above definition is flawed.

typedef unsigned short Bits; 


enum { bit01 = 1<<0, bit02 = 1<<1, bit03 = 1<<2, // . . .


Bits a = 0;


const Bits mask = bit02 | bit03 | bit06;


// . . .


if( repeated( a+bit02, mask ) ) // oops!


   // . . .

Here, we've committed the common error of insufficient parenthesization of the pseudofunction. The correct definition doesn't leave anything to chance:

#define repeated(b, m) ((b) & (m) & ((b) & (m))-1) 

Except side effects. A moderately different use of the pseudofunction will yield a result that's both incorrect and ambiguous:

if( repeated( a+=bit02, mask ) ) // double oops! 


   // . . .

The first argument to the pseudofunction has a side effect. If repeated were a real function, the side effect would take place exactly once, before the function was called. In the case of this particular definition of repeated, the side effect will occur twice, and in an unspecified order (see Gotcha #14). Pseudofunctions are particularly dangerous because their use resembles that of real functions, but they have very different semantics. Because of this resemblance to real functions, even experienced C++ programmers tend to misuse pseudofunctions, because they assume they're calling a function.

In C++, an inline function is almost always preferable to a pseudofunction, because it will display proper function call semantics; it has the same meaning as a non-inline function:

inline Bits repeated( Bits b, Bits m ) 


   { return b & m & (b & m)-1; }

Macros used as pseudofunctions also suffer from the same scoping problems that affect macros used as manifest constants (see Gotcha #25):

gotcha26/execbump.cpp

int kount = 0; 


#define execBump( func ) (func(), ++kount)


// . . .


void aFunc() {


   extern void g();


   int kount;


   while( kount++ < 10 )


       execBump( g ); // increment local kount!


}

The user of the execBump pseudofunction is (one hopes) unaware that it references a variable spelled kount and has inadvertently modified the value of the local kount variable rather than the global one. A better solution would employ a function:

gotcha26/execbump.cpp

int kount = 0; 


inline void execBump( void (*func)() )


   { func(); ++kount; }

The use of an inline function binds the identifier kount to the global variable when the function body is compiled. The name will not be re-bound to a different kount variable when the function is called. (But we're still using a global variable; see Gotcha #3.)

An even better solution might employ a function object to better encapsulate the count:

gotcha26/execbump.cpp

class ExecBump { // Monostate. See Gotcha #69. 


 public:


   void operator ()( void (*func)() )


       { func(); ++count_; }


   int get_count() const


              { return count_; }


 private:


   static int count_;


};


// . . .


int ExecBump::count_ = 0;


// . . .


void aFunc() {


   extern void g();


   ExecBump exec;


   int count = 0;


   while( count++ < 10 )


       exec( g );


}

The proper uses of pseudofunctions are relatively rare and usually involve the use of the __LINE__, __FILE__, __DATE__, or __TIME__ preprocessor symbols:

gotcha28/myassert.h

#define myAssert( e ) ((!(e))?void(std::cerr << "Failed: " \ 


       << #e << " line " << __LINE__ << std::endl): void())

See also Gotcha #28.