static const int problem

I

Ian Collins

Paavo said:
(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...
 
I

Ian Collins

Paavo said:
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.
 
I

Ian Collins

Paavo said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,905
Latest member
Kristy_Poole

Latest Threads

Top