Inline vs constexpr for a static const getter?

Question

In the following piece of code, what function will allow the best optimization for an external use and why ? Is the "Version 4" allowed in C++ 2011 ?

template<unsigned int TDIM> class MyClass 
{
    public:
        static inline unsigned int size()           {return _size;} // Version 1
        static inline const unsigned int size()     {return _size;} // Version 2
        static constexpr unsigned int size()        {return _size;} // Version 3
        static inline constexpr unsigned int size() {return _size;} // Version 4
    protected:
        static const unsigned int _size = TDIM*3;
};

Thank you very much.

Answer 1

I believe that the code in <random> sets a good example, but also need not be followed slavishly. In <random> you see both of these styles:

template<unsigned int TDIM> class MyClass 
{
    public:
        static constexpr unsigned int size() {return _size;}  // 1
        static constexpr unsigned int dim = TDIM;             // 2
    private:
        static const unsigned int _size = TDIM*3;
};

The choice between 1 and 2 is largely stylistic. They are both resolved at compile time when used in a way that demands a compile-time result. Do you want your clients to type () or not? Is there generic code that will need to use one style or the other? Satisfying the requirements of generic code is key here.

Use of the inline keyword has no impact here. I consider it overly verbose, but it does no harm and has no impact if you use it.

Adding const to a return type will have no impact here. I consider it overly verbose, but it does no harm and has no impact if you use it.

If you use the function style, but do not use constexpr :

    static unsigned int size() {return _size;}

then this function can not be called at compile-time, and thus can not be used in a context which expects a compile-time constant. That may not cause any harm for your application or your clients if they don't need such functionality. But imho, if you've got constexpr in the toolbox, this is the perfect place to use it. If you do a future client can do stuff like this:

template <unsigned N> struct B {};
constexpr auto myclass = MyClass<3>();
// ...
// lots of code here
// ...
B<myclass.size()> b;

These two are equivalent:

        static constexpr unsigned int dim = TDIM;        // 2
        static const unsigned int dim = TDIM;            // 3

but only because the involved type is integral. If the type is not integral, then you have to use constexpr and the type has to have a constexpr constructor:

class A
{
    unsigned _i;
public:
    constexpr A(unsigned i) : _i(i) {}
};

template<unsigned int TDIM> class MyClass 
{
    public:
        static constexpr unsigned int size() {return _size;}
        static constexpr unsigned int dim = TDIM;
        static constexpr A a = A(dim);
    private:
        static const unsigned int _size = TDIM*3;
};

Everyone here, including myself, is still learning how to use constexpr . So +1 on the question.

Answer 2

static const integer values are treated as constants and not as variables by the compiler. They might not end up taking any memory at all depending on the constant. In all your examples, the function will return a constant value and will pretty much always get inlined (as mentioned above, the inline keyword isn't necessary in this example since all declarations are inline already).

The above code isn't different from the perspective of the compiler than this:

static unsigned int size() { return 42; }

Also the 'const' keyword in version 2 is not necessary. I believe it only makes sense if you return a pointer or a reference.