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.