Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Is there benefit to having both class enum and "traditional" enum (other than backward compatibility)?

28 views
Skip to first unread message

K. Frank

unread,
Jun 17, 2015, 9:18:42 AM6/17/15
to
Hello Group!

If one were to redesign c++ without backward compatibility
as a goal, would it make sense to include both class enum
and old-fashioned (pre-c++11) enum?

Are there use cases where plain enum is better (enough
better to be worth the weight of having two different kinds
of enum in the language)?


Thanks.


K. Frank

Luca Risolia

unread,
Jun 17, 2015, 11:33:01 AM6/17/15
to
On 17/06/2015 15:18, K. Frank wrote:
> If one were to redesign c++ without backward compatibility
> as a goal, would it make sense to include both class enum
> and old-fashioned (pre-c++11) enum?

Why not (see below).

> Are there use cases where plain enum is better (enough
> better to be worth the weight of having two different kinds
> of enum in the language)?

old-style enum's can make the code more readable in some cases. For
example, I find them useful for getting elements from tuples or pairs:

enum {Description, RGB};

std::map<std::string, std::uint32_t> colors = {
{"white", 0xffffff}, {"black", 0x000000} /*...*/
};

// somewhere else...
for (const auto& c : colors)
std::cout << std::get<Description>(c) << ' '
<< std::hex << std::get<RGB>(c) << '\n';

The same readability cannot be achieved with strongly typed enums (or
type aliases).

There are other cases in template metaprogramming where they are useful.

K. Frank

unread,
Jun 17, 2015, 3:24:46 PM6/17/15
to
Hi Luca!
Nice example.

> There are other cases in template metaprogramming where they are useful.

Are all of the use cases you have in mind based
on the fact that you can templatize on integral
values, but not other kinds of values, and therefore
there is a role for (old-fashioned) enums that are
integral types?

If you were redesigning c++ (without regard to
backward compatibility), given that each additional
language feature adds complexity, would you

keep both kinds of enums (with this
template usage in mind);

keep only class enums, and work out
some other way to templatize on class
enums;

or keep only class enums and forgo the
ability to templatize on enums?


Thanks.


K. Frank
0 new messages