Boost logo

Boost :

Subject: Re: [boost] interest in a flag library
From: Masse Nicolas (masse.nicolas_at_[hidden])
Date: 2018-10-26 21:06:22


Right now my code provide the "+" and the "-" operators to set or reset
flags. Anyway, I see no problem in adding some named function for those who
prefer using them.

Masse Nicolas.

Le ven. 26 oct. 2018 à 09:35, Andrzej Krzemienski via Boost <
boost_at_[hidden]> a écrit :

> czw., 25 paź 2018 o 23:28 Masse Nicolas via Boost <boost_at_[hidden]>
> napisał(a):
>
> > Hi all,
> >
> > This is the first time I post on this mailing list :).
> > I'm posting because i'd like to know if people would be interested in a
> > library to treat enum types as flags. I find that's something which is
> > lacking in the language since the introduction of strongly typed enums,
> and
> > I've since written some code in order to do this.
> > So far I've seen some discussion on this mailing list about that, but it
> > doesn't seems that any library have been written yet.
> > So do you think it is worth the effort of porting and documenting my code
> > so that it can integrated into boost, or not?
> >
>
> Hi. I would use a type-safe library for flags. I am missing one today.
> However, given that you provide your own type (which is good IMO), I would
> expect a different interface that reflects the meaning more directly. I
> consider bit-wise operations to be a hack rather than a proper solution.
> Expression `flags & Flags::EXEC` is quite idiomatic, but when I want to
> reset a flag, I have to write `flag &=~ Flag::EXEC` (which I call an 'oil
> lamp' operator), which is difficult to understand and likely to get wrong.
> (In fact, I am not sure I got it right in this example.)
>
> I would rather expect an interface using named functions or indexing
> operator:
>
> ```
> if (!flags[Flag::READ])
> flags.reset(Flag::EXEC);
> ```
>
> Regards,
> &rzej;
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk