On 4 May 2017 at 15:24, Kjell Ahlstedt <kjellahlst...@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.
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Reply via email to