static const int problem

[Öö Tiib]

And the reason is...?

Enumerator may cause inconvenience in C++ when such constant value
should be of particular integral type.

 

[Ian Collins]

(e-mail address removed) wrote in


Yes, this is a declaration which will need a definition in some source
file somewhere. If there is no such definition, the linker may complain
or not, depending on the usage of this symbol and optimization levels,
and obviously depending on which compiler you use.

Unfortunately, at least some MSVC versions fail to compile the correct
code with the definition added, complaining about multiply defined
symbols. So to avoid all the hassle I would suggest just to use:

class C {
private:
enum constants {
m_static = 2
};

Which compilers? I haven't had to resort to that kludge for 20 years or
so...

 

[Ian Collins]

MSVC++ 2010 and probably all earlier versions, have not tried with later
ones.


What kludge? To my mind, a const static integral member is a huge kludge.
It is like a Cheshire/Bohr half-existing cat, at one moment it is a real
object occupying a real memory region, on the next it is not. It appears
C++11 has made the situation worse with the ODR-use thing, making it
virtually impossible to predict if such a thing should be defined in a
compilation unit in addition to a declaration or not.

Looking my code, nearly all const static integral members are private
sizes, limits (buffer sizes mainly) and IP port numbers which never have
their address evaluated. If something is a size, I prefer to declare it
as a size_t. At least one example I found was > INT_MAX, which I guess
would be undefined as an enum value.

 

[Öö Tiib]

I guess that's why C++11 introduced strongly-typed enums.

The underlying type of C++11 fixes the issues caused by signedness and
byte size of enumerator. That is lot better, but type may still be needed
for other reasons, for example for overload resolution.

4.5/4: "A prvalue of an unscoped enumeration type whose underlying type
is fixed (7.2) can be converted to a prvalue of its underlying type.
Moreover, if integral promotion can be applied to its underlying type,
a prvalue of an unscoped enumeration type whose underlying type is
fixed can also be converted to a prvalue of the promoted underlying
type."

I can't find where it defines any rank differences to those conversions.
That seems to make it ambiguous what overload to choose. No such problem
with 'constexpr char' for example for what overload that expects char is
exact match.

 

[Ian Collins]

And this is ruined by passing it to an innocent-looking std::max() or
adding to an iterator.


enum constants: size_t { kMaxSize = size_t(-1) };

I'm talking code written over many years.