Boost logo

Boost :

From: David A. Greene (greened_at_[hidden])
Date: 2002-11-05 15:10:54


Hi gang,

Has anyone come across a compile-time print metafunction? I
searched on Google the other day and was surprised that I
coulnd't find anything. In a pinch I drafted the following:

   template<typename Message>
   struct ct_print {
     ct_print(unsigned int j) {};
   };

   #ifdef CT_DEBUG
   #define CT_PRINT(Context, Message) \
      class Context##_print { \
      public: \
         typedef ct_print<Message> type_not_likely_to_be_declared; \
         type_not_likely_to_be_declared member; \
         Context##_print(void) : member(-1) { \
         }; \
      };
   #else
   #define CT_PRINT(Context, Message)
   #endif

Here's an example of its use (ignore home-brew MPL for the moment):

   typedef mpl::make_typelist_5<char, short, int, long, float>::type
   list_type;
   CT_PRINT(list_is, list_type::self_type);

I've found this to be an invaluable tool during my development of
several complex metaprograms. Even so, there are several problems
with this implementation:

- It requires that Context be unique for each invocation of
   CT_PRINT.

- It assumes type_not_likely_to_be_declared will never be passed
   to CT_PRINT.

- It assumes the compiler (g++ -Wall in my case) will warn
   about initializing an unsigned int with a negative value.

- g++ does not emit the warning when CT_PRINT is used in
   class scope. I have no idea why. It works great in
   function scope.

- It's not very useful when working with typedefs.
   CT_PRINT(list_is, list_type) will print "list_type,"
   not "typelist<char, typelist<short ...> > > > >."
   Curiously, it does expand list_type::self_type correctly.
   I'm sure this is compiler-dependent.

Is this interesting to anyone? Does anyone have suggestions
on how to improve this and make it more generally applicable?

                       -Dave

-- 
"Some little people have music in them, but Fats, he was all music,
  and you know how big he was."  --  James P. Johnson

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk