Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-07 14:40:38


Terje Slettebø <tslettebo_at_[hidden]> writes:

> 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.

I buy everything but the last sentence. What do they mean? Does the
thing go into the link map? If not, what?

> 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?

The rule is that you can't in general take the address of a
BOOST_STATIC_CONSTANT.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

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