Re: enums that are really just sets of constants

[Kjell Ahlstedt <kjellahlstedt gmail com>]

Den 2017-04-19 kl. 10:37, skrev Murray Cumming:

In the ABI-breaking versions of glibmm and gtkmm, we have recently
changed the enums to be C++11 "enum class"s. This is generally a
welcome improvement.
- Their values are, for instance, Things::ONE, rather than THINGS_ONE.
- Their values do not convert implicitly to other types such as int or
bool, helping the compiler to find some programmer mistakes.

We are also gradually moving the enums inside classes when they are
typically only used with that class.

However, some of the C enums that we wrap are actually meant to be
integer constants, so it seems that we cannot and should not use "enum
class" for these. So I wonder what is the most "modern C++" way to do
this while keeping the new-style syntax. Here are two possibilities:

1. Use old-style enums inside a class:
But shouldn't we just avoid old-style enums completely?


2. Use constexpr int constants inside a class:
But shouldn't we use some kind of enum to group the values together?

Have we decided what to do? According to other posts in this thread there are 4 possibilities:

1. Old-style enums inside a class.
2. constexpr int constants inside a class.
3. Old-style enums inside a namespace.
4. constexpr int constants inside a namespace.

A namespace can't be declared inside a class. We can't declare Gtk::ResponseType inside Gtk::Dialog, if ResponseType is a namespace.

Jonathan Wakeley has pointed out that a class has greater overhead than a namespace. The overhead can be kept to a minimum, however. These classes won't have virtual methods, so they won't have RTTI. They won't need a public constructor. It can be made illegal to create instances of them. They can be declared final to stop people from deriving from them.