An enum X : int
(C#) or enum class X : int
(C++11) is a type that has a hidden inner field of int
that can hold any value. In addition, a number of predefined constants of X
are defined on the enum. It is possible to cast the enum to its integer value and vice versa. This is all true in both C# and C++11.
In C# enums are not only used to hold individual values, but also to hold bitwise combinations of flags, as per Microsoft's recommendation. Such enums are (usually, but not necessarily) decorated with the [Flags]
attribute. To make the lives of developers easier, the bitwise operators (OR, AND, etc...) are overloaded so that you can easily do something like this (C#):
void M(NumericType flags);
M(NumericType.Sign | NumericType.ZeroPadding);
I am an experienced C# developer, but have been programming C++ only for a couple of days now, and I am not known with the C++ conventions. I intend to use a C++11 enum in the exact same way as I was used to do in C#. In C++11 the bitwise operators on scoped enums are not overloaded, so I wanted to overload them.
This solicited a debate, and opinions seem to vary between three options:
A variable of the enum type is used to hold the bit field, similar to C#:
void M(NumericType flags); // With operator overloading: M(NumericType::Sign | NumericType::ZeroPadding); // Without operator overloading: M(static_cast<NumericType>(static_cast<int>(NumericType::Sign) | static_cast<int>(NumericType::ZeroPadding)));
But this would counter the strongly typed enum philosophy of C++11's scoped enums.
Use a plain integer if you want to store a bitwise combination of enums:
void M(int flags); M(static_cast<int>(NumericType::Sign) | static_cast<int>(NumericType::ZeroPadding));
But this would reduce everything to an
int
, leaving you with no clue as to which type you're supposed to put in the method.Write a separate class that will overload operators and hold the bitwise flags in a hidden integer field:
class NumericTypeFlags { unsigned flags_; public: NumericTypeFlags () : flags_(0) {} NumericTypeFlags (NumericType t) : flags_(static_cast<unsigned>(t)) {} //...define BITWISE test/set operations }; void M(NumericTypeFlags flags); M(NumericType::Sign | NumericType::ZeroPadding);
(full code by user315052)
But then you have no IntelliSense or whatever support to hint you at the possible values.
I know this is a subjective question, but: What approach should I use? What approach, if any, is the most widely recognized in C++? What approach do you use when dealing with bit fields and why?
Of course since all three approaches work, I'm looking for factual and technical reasons, generally accepted conventions, and not simply personal preference.
For example, because of my C# background I tend to go with approach 1 in C++. This has the added benefit that my development environment can hint me on the possible values, and with overloaded enum operators this is easy to write and understand, and quite clean. And the method signature shows clearly what kind of value it expects. But most people here disagree with me, probably for good reason.
8 Answers 8
The simplest way is to provide the operator overloads yourself. I am thinking of creating a macro to expand the basic overloads per type.
#include <type_traits>
enum class SBJFrameDrag
{
None = 0x00,
Top = 0x01,
Left = 0x02,
Bottom = 0x04,
Right = 0x08,
};
inline SBJFrameDrag operator | (SBJFrameDrag lhs, SBJFrameDrag rhs)
{
using T = std::underlying_type_t <SBJFrameDrag>;
return static_cast<SBJFrameDrag>(static_cast<T>(lhs) | static_cast<T>(rhs));
}
inline SBJFrameDrag& operator |= (SBJFrameDrag& lhs, SBJFrameDrag rhs)
{
lhs = lhs | rhs;
return lhs;
}
(Note that type_traits is a C++11 header and std::underlying_type_t is a C++14 feature.)
-
6std::underlying_type_t is C++14. Can use std::underlying_type<T>::type in C++11.ddevienne– ddevienne08/04/2015 15:21:01Commented Aug 4, 2015 at 15:21
-
14Why are you using
static_cast<T>
for input, but C-style cast for result here?Ruslan– Ruslan01/05/2016 17:29:28Commented Jan 5, 2016 at 17:29 -
2@Ruslan I second this questionaudiFanatic– audiFanatic07/08/2016 16:18:41Commented Jul 8, 2016 at 16:18
-
1If
SBJFrameDrag
is defined in a class and the|
-operator is later used in the definitions of the same class, how would you define the operator such that it could be used within the class?HelloGoodbye– HelloGoodbye12/19/2018 15:36:56Commented Dec 19, 2018 at 15:36 -
1Using
std::underlying_type
provides greater forwards compability, @poizan42, in that the operators will automagically update if the enum's underlying type is changed in the future.Justin Time - Reinstate Monica– Justin Time - Reinstate Monica09/25/2019 19:26:05Commented Sep 25, 2019 at 19:26
Historically, I would always have used the old (weakly-typed) enumeration to name the bit constants, and just used the storage class explicitly to store the resulting flag. Here, the onus would be on me to make sure my enumerations fit in the storage type, and to keep track of the association between the field and it's related constants.
I like the idea of strongly-typed enums, but I'm not really comfortable with the idea that variables of enumerated type may contain values that aren't among that enumeration's constants.
Eg, assuming the bitwise or has been overloaded:
enum class E1 { A=1, B=2, C=4 };
void test(E1 e) {
switch(e) {
case E1::A: do_a(); break;
case E1::B: do_b(); break;
case E1::C: do_c(); break;
default:
illegal_value();
}
}
// ...
test(E1::A); // ok
test(E1::A | E1::B); // nope
For your 3rd option, you need some boilerplate to extract the enumeration's storage type. Assuming we want to force an unsigned underlying type (we can handle signed too, with a little more code):
template <size_t Size> struct IntegralTypeLookup;
template <> struct IntegralTypeLookup<sizeof(int64_t)> { typedef uint64_t Type; };
template <> struct IntegralTypeLookup<sizeof(int32_t)> { typedef uint32_t Type; };
template <> struct IntegralTypeLookup<sizeof(int16_t)> { typedef uint16_t Type; };
template <> struct IntegralTypeLookup<sizeof(int8_t)> { typedef uint8_t Type; };
template <typename IntegralType> struct Integral {
typedef typename IntegralTypeLookup<sizeof(IntegralType)>::Type Type;
};
template <typename ENUM> class EnumeratedFlags {
typedef typename Integral<ENUM>::Type RawType;
RawType raw;
public:
EnumeratedFlags() : raw() {}
EnumeratedFlags(EnumeratedFlags const&) = default;
void set(ENUM e) { raw |= static_cast<RawType>(e); }
void reset(ENUM e) { raw &= ~static_cast<RawType>(e); };
bool test(ENUM e) const { return raw & static_cast<RawType>(e); }
RawType raw_value() const { return raw; }
};
enum class E2: uint8_t { A=1, B=2, C=4 };
typedef EnumeratedFlags<E2> E2Flag;
This still doesn't give you IntelliSense or autocompletion, but the storage type detection is less ugly than I originally expected.
Now, I did find an alternative: you can specify the storage type for a weakly-typed enumeration. It even has the same syntax as in C#
enum E4 : int { ... };
Because it's weakly-typed, and implicitly converts to/from int (or whatever storage type you choose), it feels less weird to have values which don't match the enumerated constants.
The downside is that this is described as "transitional" ...
NB. this variant adds its enumerated constants to both the nested and the enclosing scope, but you can work around this with a namespace:
namespace E5 {
enum Enum : int { A, B, C };
}
E5::Enum x = E5::A; // or E5::Enum::A
-
1Another downside of weakly typed enums is that their constants pollute my namespace, since they don't need to be prefixed with the enum name. And that may also cause all kinds of weird behavior if you have two different enums both with a member with the same name.Daniel A.A. Pelsmaeker– Daniel A.A. Pelsmaeker04/09/2013 13:44:09Commented Apr 9, 2013 at 13:44
-
That's true. The weakly-typed variant with the specified storage type adds its constants to both the enclosing scope and its own scope, iiuc.Useless– Useless04/09/2013 14:00:44Commented Apr 9, 2013 at 14:00
-
The unscoped enumerator is only declared in the surrounding scope. Being able to qualify it by the enum-name is part of lookup rules, not the declaration. C++11 7.2/10: Each enum-name and each unscoped enumerator is declared in the scope that immediately contains the enum-specifier. Each scoped enumerator is declared in the scope of the enumeration. These names obey the scope rules defined for all names in (3.3) and (3.4).Lars Viklund– Lars Viklund03/10/2014 20:56:34Commented Mar 10, 2014 at 20:56
-
1with C++11 we have std::underlying_type that provides the underlying type of an enum. So we have 'template <typename IntegralType> struct Integral { typedef typename std::underlying_type<IntegralType>::type Type; }; ` In C++14 these is even more simplified to'template <typename IntegralType> struct Integral { typedef std::underlying_type_t<IntegralType> Type; };emsr– emsr05/02/2014 21:22:42Commented May 2, 2014 at 21:22
You can define type-safe enum flags in C++11 by using std::enable_if
. This is a rudimentary implementation that may be missing some things:
template<typename Enum, bool IsEnum = std::is_enum<Enum>::value>
class bitflag;
template<typename Enum>
class bitflag<Enum, true>
{
public:
constexpr const static int number_of_bits = std::numeric_limits<typename std::underlying_type<Enum>::type>::digits;
constexpr bitflag() = default;
constexpr bitflag(Enum value) : bits(1 << static_cast<std::size_t>(value)) {}
constexpr bitflag(const bitflag& other) : bits(other.bits) {}
constexpr bitflag operator|(Enum value) const { bitflag result = *this; result.bits |= 1 << static_cast<std::size_t>(value); return result; }
constexpr bitflag operator&(Enum value) const { bitflag result = *this; result.bits &= 1 << static_cast<std::size_t>(value); return result; }
constexpr bitflag operator^(Enum value) const { bitflag result = *this; result.bits ^= 1 << static_cast<std::size_t>(value); return result; }
constexpr bitflag operator~() const { bitflag result = *this; result.bits.flip(); return result; }
constexpr bitflag& operator|=(Enum value) { bits |= 1 << static_cast<std::size_t>(value); return *this; }
constexpr bitflag& operator&=(Enum value) { bits &= 1 << static_cast<std::size_t>(value); return *this; }
constexpr bitflag& operator^=(Enum value) { bits ^= 1 << static_cast<std::size_t>(value); return *this; }
constexpr bool any() const { return bits.any(); }
constexpr bool all() const { return bits.all(); }
constexpr bool none() const { return bits.none(); }
constexpr operator bool() const { return any(); }
constexpr bool test(Enum value) const { return bits.test(1 << static_cast<std::size_t>(value)); }
constexpr void set(Enum value) { bits.set(1 << static_cast<std::size_t>(value)); }
constexpr void unset(Enum value) { bits.reset(1 << static_cast<std::size_t>(value)); }
private:
std::bitset<number_of_bits> bits;
};
template<typename Enum>
constexpr typename std::enable_if<std::is_enum<Enum>::value, bitflag<Enum>>::type operator|(Enum left, Enum right)
{
return bitflag<Enum>(left) | right;
}
template<typename Enum>
constexpr typename std::enable_if<std::is_enum<Enum>::value, bitflag<Enum>>::type operator&(Enum left, Enum right)
{
return bitflag<Enum>(left) & right;
}
template<typename Enum>
constexpr typename std::enable_if_t<std::is_enum<Enum>::value, bitflag<Enum>>::type operator^(Enum left, Enum right)
{
return bitflag<Enum>(left) ^ right;
}
(削除) Note the number_of_bits
can unfortunately not be filled in by the compiler, as C++ doesn't have any way to do introspect the possible values of an enumeration. (削除ここまで)
Edit:
Actually I stand corrected, it is possible to get the compiler fill number_of_bits
for you.
Note this can handle (wildly inefficiently) a non-continuous enum value range. Let's just say it's not a good idea to use the above with an enum like this or madness will ensue:
enum class wild_range { start = 0, end = 999999999 };
But all things considered this is a quite usable solution in the end. Doesn't need any user-side bitfiddling, is type-safe and within its bounds, as efficient as it gets (I'm leaning strongly on std::bitset
implementation quality here ;)
).
-
I'm sure I missed some overloads of the operators.rubenvb– rubenvb12/19/2016 23:33:08Commented Dec 19, 2016 at 23:33
-
1
std::bitset
's API takes bit position arguments, so using1 << size_t(e)
is not correct. At least when using anenum
with continues values (0, 1, 2, ...). Adapted your code, and wrote a test, and found it out :)ddevienne– ddevienne01/04/2022 12:02:38Commented Jan 4, 2022 at 12:02 -
That
number_of_bits
isn't what you think it is - that's the number of bits used to representEnum
, not the maximum value declared for it.Toby Speight– Toby Speight02/19/2022 21:32:35Commented Feb 19, 2022 at 21:32
I (削除) hate (削除ここまで) detest macros in my C++14 as much as the next guy, but I've taken to using this all over the place, and quite liberally too:
#define ENUM_FLAG_OPERATOR(T,X) inline T operator X (T lhs, T rhs) { return (T) (static_cast<std::underlying_type_t <T>>(lhs) X static_cast<std::underlying_type_t <T>>(rhs)); }
#define ENUM_FLAGS(T) \
enum class T; \
inline T operator ~ (T t) { return (T) (~static_cast<std::underlying_type_t <T>>(t)); } \
ENUM_FLAG_OPERATOR(T,|) \
ENUM_FLAG_OPERATOR(T,^) \
ENUM_FLAG_OPERATOR(T,&) \
enum class T
Making use as simple as
ENUM_FLAGS(Fish)
{
OneFish,
TwoFish,
RedFish,
BlueFish
};
And, as they say, the proof is in the pudding:
ENUM_FLAGS(Hands)
{
NoHands = 0,
OneHand = 1 << 0,
TwoHands = 1 << 1,
LeftHand = 1 << 2,
RightHand = 1 << 3
};
Hands hands = Hands::OneHand | Hands::TwoHands;
if ( ( (hands & ~Hands::OneHand) ^ (Hands::TwoHands) ) == Hands::NoHands)
{
std::cout << "Look ma, no hands!" << std::endl;
}
Feel free to undefine any of the individual operators as you see fit, but in my highly-biased opinion, C/C++ is for interfacing with low-level concepts and streams, and you can pry these bitwise operators out of my cold, dead hands and I'll fight you with all the unholy macros and bit-flipping spells I can conjure to keep them.
-
2If you detest macros so much, why not use a proper C++ construct and write some template operators instead of the macros? Arguably, the template approach is better because you can use
std::enable_if
withstd::is_enum
to restrict your free operator overloads to only working with enumerated types. I've also added comparison operators (usingstd::underlying_type
) and the logical not operator to further bridge the gap without losing the strong typing. The only thing I can't match is implicit conversion to bool, butflags != 0
and!flags
are sufficient for me.monkey0506– monkey050610/26/2016 07:50:06Commented Oct 26, 2016 at 7:50 -
@monkey0506 because you only want to define bitwise operators for some enumsCaleth– Caleth03/23/2020 12:47:28Commented Mar 23, 2020 at 12:47
-
@Caleth if you're using
std::enable_if
then you could use any compile-time constant constraint of your choosing, including a cherry-picked list of types to implement the operators for. There's nothing about that requirement, to only have bitwise operators for certain types, that precludes using templated overloads of free operators.monkey0506– monkey050603/24/2020 22:28:07Commented Mar 24, 2020 at 22:28
A short example of enum-flags below, looks pretty much like C#.
About the approach, in my opinion: less code, less bugs, better code.
#indlude "enum_flags.h"
ENUM_FLAGS(foo_t)
enum class foo_t
{
none = 0x00
,a = 0x01
,b = 0x02
};
ENUM_FLAGS(foo2_t)
enum class foo2_t
{
none = 0x00
,d = 0x01
,e = 0x02
};
int _tmain(int argc, _TCHAR* argv[])
{
if(flags(foo_t::a & foo_t::b)) {};
// if(flags(foo2_t::d & foo_t::b)) {}; // Type safety test - won't compile if uncomment
};
ENUM_FLAGS(T) is a macro, defined in enum_flags.h (less then 100 lines, free to use with no restrictions).
-
1is file enum_flags.h the same as in 1st revision of your question? if yes, you can use revision URL to refer to it: http://programmers.stackexchange.com/revisions/205567/1gnat– gnat07/21/2013 15:35:32Commented Jul 21, 2013 at 15:35
-
+1 looks good, clean. I'll try this out in our SDK project.That Realtor Programmer Guy– That Realtor Programmer Guy07/08/2014 19:11:00Commented Jul 8, 2014 at 19:11
-
1@GaretClaborn This is what I'd call clean: paste.ubuntu.com/23883996sehe– sehe01/29/2017 00:21:45Commented Jan 29, 2017 at 0:21
-
1Of course, missed the
::type
there. Fixed: paste.ubuntu.com/23884820sehe– sehe01/29/2017 04:04:16Commented Jan 29, 2017 at 4:04 -
@sehe hey, template code is not supposed to be legible and make sense. what is this witchcraft? nice.... is this snippet open to use lolThat Realtor Programmer Guy– That Realtor Programmer Guy02/21/2017 09:13:59Commented Feb 21, 2017 at 9:13
Typically you'd define a set of integer values that correspond to single-bit set binary numbers, then add them together. This is the way C programmers usually do it.
So you'd have (using the bitshift operator to set the values, eg 1 << 2 is the same as binary 100)
#define ENUM_1 1
#define ENUM_2 1 << 1
#define ENUM_3 1 << 2
etc
In C++ you have more options, define a new type rather that is an int (use typedef) and similarly set values as above; or define a bitfield or a vector of bools. The last 2 are very space efficient and make a lot more sense for dealing with flags. A bitfield has the advantage of giving you type checking (and therefore intellisense).
I'd say (obviously subjective) that a C++ programmer should use a bitfield for your problem, but I tend to see the #define approach used by C programs a lot in C++ programs.
I suppose the bitfield is the closest to C#'s enum, why C# tried to overload an enum to be a bitfield type is weird - an enum should really be a "single-select" type.
-
3C++14 allows you to define binary literals (e.g.
0b0100
) so the1 << n
format is sort of obsolete.Rob K– Rob K03/16/2015 20:55:18Commented Mar 16, 2015 at 20:55 -
Maybe you meant bitset instead of bitfield.Jorge Bellon– Jorge Bellon12/21/2018 16:49:31Commented Dec 21, 2018 at 16:49
-
@RobK Ugh, I rather prefer the rhs of
<<
to indicate the set bit directly and don't want to count the 0's around the 1.Ray– Ray05/20/2020 00:50:26Commented May 20, 2020 at 0:50
Instead of doing all this work, wouldn't it be much easier to use a struct of bit fields?
struct MyFlags {
uint8_t flagOne:1;
uint8_t flagTwo:1;
uint8_t flagThree:1;
uint8_t flagFour:1;
uint8_t flagFive:1;
uint8_t flagSix:1;
uint8_t flagSeven:1;
uint8_t flagEight:1;
};
and then you can set/test it as
MyFlags flags = {};
flags.flagThree = true;
? Of course that won't help if you need to extract the raw number, as it seems the standard doesn't actually guarantee a layout (though at least Apple platforms seem to lay it out as you'd expect).
There is yet another way to skin the cat:
Instead of overloading the bit operators, at least some might prefer to just add a 4 liner to help you circumvent that nasty restriction of scoped enums:
#include <cstdio>
#include <cstdint>
#include <type_traits>
enum class Foo : uint16_t { A = 0, B = 1, C = 2 };
// ut_cast() casts the enum to its underlying type.
template <typename T>
inline auto ut_cast(T x) -> std::enable_if_t<std::is_enum_v<T>,std::underlying_type_t<T>>
{
return static_cast<std::underlying_type_t<T> >(x);
}
int main(int argc, const char*argv[])
{
Foo foo{static_cast<Foo>(ut_cast(Foo::B) | ut_cast(Foo::C))};
Foo x{ Foo::C };
if(0 != (ut_cast(x) & ut_cast(foo)) )
puts("works!");
else
puts("DID NOT WORK - ARGHH");
return 0;
}
Granted, you have to type the ut_cast()
thing each time, but on the up side, this yields more readable code, in the same sense as using static_cast<>()
does, compared to implicit type conversion or operator uint16_t()
kind of things.
And let's be honest here, using type Foo
as in the code above has its dangers:
Somewhere else someone might do a switch case over variable foo
and not expect that it holds more than one value...
So littering the code with ut_cast()
helps alert readers that something fishy is going on.
enum E { A = 1, B = 2, C = 4, };
, the range is0..7
(3 bits). Thus, the C++ standard explicitly guarantees that #1 will always be a viable option. [Specifically,enum class
defaults toenum class : int
unless otherwise specified, and thus always has a fixed underlying type.])