[boost] Metaprogramming: Using static const or enum?

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-01-07 09:35:56

Hi.

BOOST_STATIC_CONST is defined in Boost.Config as:

#  ifdef BOOST_NO_INCLASS_MEMBER_INITIALIZATION
#       define BOOST_STATIC_CONSTANT(type, assignment) enum { assignment }
#  else
#     define BOOST_STATIC_CONSTANT(type, assignment) static const type
assignment
#  endif

Thus, it prefers static const, if it's possible to initialise it in-class,
on the given compiler, as allowed in the standard. However, "C++ Templates:
The Complete Guide" says about the difference between the two (p. 304):

--- Start quote ---

Static constant members are lvalues. So, if you have a declaration such as

void foo(int const&);

and you pass it the result of a metaprogram

foo(Pow3<7>::result);

a compiler must pass the address of Pow3<7>::result, which forces the
compiler to instantiate and allocate the definition for the static member.
As a result, the computation is no longer limited to a pure "compile-time"
effect.

Enumerations aren't lvalues (that is, they don't have an address). So when
you pass them "by reference," no static memory is used. It's almost exactly
as if you passed the computed value as a literal. These considerations
motivate us to use enumeration values in all metaprograms throughout this
book.

--- End quote ---

I like static const, as I think it conveys more succinctly what it's about,
and the enum appears more like a hack (for compilers not handling static
const in-class initialisation). However, if this means it may need an
out-of-class definition, as well, perhaps this could need to be
reconsidered?

The point is also confirmed by the following test (on Intel C++, which uses
static const):

struct Test
{
  enum { value=1 }; // Ok
//  BOOST_STATIC_CONSTANT(int, value=1); // Gives link-error
};

void f(const int &)
{
}

int main()
{
f(Test::value);
}

If pass by value is used in f(), it works, of course. So maybe pass by const
reference for integral constants typically isn't used, so that this isn't a
problem?

Regards,

Terje