Re: [boost] Any interest in "flags" (type safety for enumerationbitsets)

From: iain.denniston_at_[hidden]
Date: 2007-06-12 04:28:17

> your library sounds interesting to me, even if I have some questions:

Glad it's of interest :o) Hope this helps clarify things:

> 1) what requirements the enumeration type should satisfy? For example, am 
> I
> obliged to declare
> 2's powers? such as
> enum my_enum { flag1 = 1, flag2 = 2, flag3 = 4, ..... };

There would be no requirements as such - although only values that can be 
sensibly or'd together would make any sense. So normally I'd expect power of 
two's would be used, but there would be nothing to stop people using 
non-power of two's. Apart from anything else this would allow people to use 
bit masks if required (so long as the mask belongs to the enum there is no 
problem).

> 2) when you assign a value to a boost::flags<my_enum>, do you use my_enum
> constants?
>    It seems that flag1 | flag2 is an int, thus how can you distinguish
> between flag1 | flag2 and another user provided integral constant. Do you
> overload the "bitwise or" to produce an intermediate object???

Overloading the relevant operators is the idea - although it could create 
potentially complex statements that result in a lot of temporary objects, I'd 
hope the compiler would be clever enough to optimise them away. Of course, 
even if the compiler did not optimise them all away, I would suspect that in 
most cases it is unlikely to pose a problem. Certainly I'd be surprised to 
find it causing performance issues.

> 3) I agree with you about the usefulness of such a library, since a 
> compile
> time check will assure that whenever the code is actually executed,
> properties will be always in a sensible state (eliminating the annoying 
> and
> error prone runtime validation). If the programmer consider every notable
> case, then a static checked flag will give us the same assurances which
> could give us a collection of methods, one for each particular flag
> combination.

The more errors we can push back to the compiler the better!

> When you speak about the vulnerability of your library, do you refer to 
> the
> fact that a cast to enum could be used to avoid the static type check?

Exactly - but if a user is doing that then there is little hope :o) As I 
said, it's not an ideal solution, but IMO far better than we currently have. 
Besides, when it's possible to cast a type to any other type there is only 
so much can be done to protect against bad values.

Hope that answers you questions - feel free to ask more! (Or ask again if 
I've not answered your questions properly.)

Iain