RE: CPP (preprocessor) quandry

[Eljay Love-Jensen <eljay at adobe dot com>]

Hi Buddy,

The macro wraps the data type in a struct, so as to reduce namespace pollution.

In particular, it avoids...
typedef enum {a,b,c} EnumWhatever;
...such that a, b, c and EnumWhatever now reside in the global (or current) 
namespace.

I have found a GCC-centric solution.  But (unfortunately) the code needs to 
run on other compilers.

#define $MkEnum(name$, enum$...) \
struct name$ {\
  typedef enum { enum$ } Type;\
  Type m;\
  explicit name$ (Type in) : m(in) { }\
  operator Type () const { return m; };\
  }

NOTE: local convention dictates that $ is used to prefix macros (function 
macros or simple substitution), and $ suffix for the macro's 
parameters.  The $ is digestable by all the preprocessors / compilers we 
care about.  Less chance of spurious macro vs. local identifier collision.

Something similar to this trick was proposed / introduced by Stroustrup in 
his C++ Programming Language (3rd and Special editions).  Not the macro 
part, but the wrapping of a POD in a struct to have somewhat stronger type 
safety.  Getting that stronger type safety is the ultimate purpose of the 
macros; the macros serve to reduce repetitive typing -- and thus reduce 
mistakes and simplify maintenance.

A better solution would be to use a language that has this facility 
native.  Stroupstrup told me (paraphrased), "No one is stopping you from 
writing your own language."  (I think he was a little tired of hearing a 
bazillion requests and suggestions for how to "improve" C++.)

Sincerely,
--Eljay
(I hate macros)


At 12:43 PM 11/22/2002 -0500, Buddy Lott wrote:
> I can't think of a way to get around this, but maybe if you explain what
> purpose this solves (in other wordes, why use the macro) I could think
> of a way to accomplish the same thing.
>
> One what that comes to mind:
>
> Typedef enum { a,b,c} EnumWhatever;
> MkFoo(Whatever)