Re: enums that are really just sets of constants

[Daniel Boles <dboles src gmail com>]

On 4 May 2017 at 15:24, Kjell Ahlstedt <kjellahlstedt gmail com> wrote:

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.

So it seems that the only option is to continue using C-style enums within classes, e.g. class Dialog { enum ResponseType{} } as present.. As someone already mentioned, I see no problem with this: such an enum is not inherently bad in itself; it's only bad if chosen in o s case where another solution (enum class, constexpr, etc.) is an available and more appropriate option. As that does not apply, the C-style enum should continue to serve this purpose well.