Boost logo

Boost :

Subject: Re: [boost] Is there any interest in type-safe container of bool flags with noexcept guarantees?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-03-22 22:45:51

Le 22/03/2017 à 17:02, Roman Orlov via Boost a écrit :


I like the idea.
> On 21.03.2017 21:23, Steven Watanabe via Boost wrote:
>> what's wrong with
>> struct animal {
>> bool eats_meat : 1;
>> bool eats_grass : 1;
>> bool has_tail : 1;
>> };
Steven is right, your library is kind of a library reflecting the
previous structure.
As we don't have yet reflection, we need tag types to identify the fields.
I would expect that once we have reflection, we could provide a bit mask
interface for the previous structure. But we don't have it yet.

> There are several reasons I don't like that approach
> While declaring a variable of type 'animal' you should always keep in
> mind to initialize it with empty initializer
> animal a1; // bit fields are not initialized
> animal a2{}; // now it's ok, bits are set to zeros
I believe that this is good, as you could use it as member of POD
While I agree that it is good to initialize everything as soon as
possible, some times been able to don't initialize is the correct
answer. This is C++.
> When you want to initialize some fields (eats_grass, has_tail) you have
> to write several lines of code
> animal a1{};
> a1.eats_grass = 1;
> a1.has_tail = 1;
Well I would replace 1 by true ;-)
I find this interface clear.
> Of course, it can be done in one line with initializer list
> animal a1{0, 1, 1};
I agree that positional interfaces don't scale well as you show below.
> But we don't write a code ones, we are about to support it for a long
> time. One day we decided to add a new bit field to structure
> struct animal {
> bool can_fly : 1; // yeah, somebody puts it on the first position
> bool eats_meat : 1;
> bool eats_grass : 1;
> bool has_tail : 1;
> };
> What will happen with all of list initializers? There will be bugs we
> can't detect at compile time.
> animal a1{0, 1, 1}; // now it doesn't work properly
> We have to find all of such initializers and rewrite them
> animal a1{0, 0, 1, 1};
> To prevent this I propose to abstract from strict ordering and use
> typed entities
> animal a1{flag<eats_grass>{1}, flag<has_tail>{1}};
> And what about bitwise operations on plain structures? While working
> with bool properties conjunction and disjunction are needed fairly
> often. For each structure you'll have to implement them manually.
> Of course it's better to have it out of the box
> auto a1 = animal{flag<eats_gass>{1}} | animal{flag<eats_meat>{1}};
Have you considered to use tag classes that provide this kind of flag
We write the fftag once, but we use them much more times.

   auto a1 = animal{eats_gass{1}} | animal{eats_meat{1}};

The definition of a tag is not complex

struct eats_gass : flag<eats_gass> {
     using flag<eats_gass>::flag<eats_gass>;

BTW, why do we need an argument to the flag class
   auto a1 = animal{flag<eats_gass>{1}} | animal{flag<eats_meat>{1}};

and not simply

   auto a1 = animal{flag<eats_gass>{}} | animal{flag<eats_meat>{}};
> Sometimes it's needed to test that all flags are set or at least one.
> And again for each structure you'll have to implement it manually.
> It's better to have these functions in container
> auto a1 = animal{flag<eats_gass>{1}};
> assert( (!a1.all()) );
> assert( (!a1.any<eats_meat, has_tail>()) ); // with some syntax sugar
If you follow bit_set interface it should be

   assert( (!a1.any()) );

The last could be

   assert( (!a1.any_of<eats_meat, has_tail>()) );

You could have also compile time flags that don't have storage. The
previous any could be as well

   assert( (! (a1 & literal_typed_flag<eats_meat, has_tail>{}) ));

BTW, the construction could be done using these literals

   auto a1 = literal_typed_flag<eats_gass, eats_meat>;

literal_typed_flag could be convertible to any typed_flag that contains
at least those tags.

While I'm for the member functions in your case, if we had compile time
reflection we should use non-member function (at least until we have the
possibility to create new types)

> Managing typed entities allows you to test common properties of
> semantically different entities. For example:
> class p1;
> class p2;
> class p3;
> class p4;
> typedef typed_flags<p1, p2, p3> a; // has p3 property
> typedef typed_flags<p3, p4> b; // has p3 property too
> template<typename T, typename... Args>
> bool test_p(Args&&... args) {
> return (... && args.template test<T>());
> }
> // test p3 property from a and b
> test_p<p3>(a{flag<p3>{1}}, b{flag<p3>{1}});
Here we see that having non-member functions could help avoiding the
not-friendly x.template test<T>

   template<typename T, typename... Args>
   bool test_p(Args&&... args) {
     return (... && test<T>(args));

How typed_flags convert? Can typed_flags<a,b> be convertible to
typed_flags<a,b,c> or typed_flags<a,b,c>?

It could also be interesting to look at the tags proposed in the Range
TS to see if an adaptation could simplify the user interface.


Boost list run by bdawes at, gregod at, cpdaniel at, john at