|
Boost : |
From: tobi_at_[hidden]
Date: 2024-03-26 15:53:40
Am 2024-03-25 11:38, schrieb Andrey Semashev via Boost:
> On 3/24/24 02:22, Tobias Loew via Boost wrote:
>> Am 2024-03-23 15:07, schrieb ÐмиÑÑий ÐÑÑ
ипов via Boost:
>>> Ñб, 23 маÑ. 2024â¯Ð³. в 15:52, Tobias Loew via Boost
>>> <boost_at_[hidden]>:
>>>>
>>>> Hi,
>>>>
>>>> I would like to gauge interest in a library that makes the usage of
>>>> flag-like enumerations safer.
>>>> The library is called Boost.Flags, and its key features are
>>>> ...
>>>> Example on Godbolt: https://godbolt.org/z/qbojncnd7
>>>
>>> From the reading of the docs I gathered that the library relies on
>>> operators in the global namespace, rather than using a macro to
>>> define
>>> operators in an enum's namespace. This has a certain flaw:
>>> https://godbolt.org/z/xePjK3es6
>>
>> The described flaw can be avoided by either including flags.hpp before
>> `foobar` or by `using ::operator |` in the enums namespace.
>> (https://godbolt.org/z/rT5678n4f)
>>
>> I could add a macro the enables ADL for the current namespace, e.g.
>>
>> #define BOOST_FLAGS_ENABLE_ADL_FOR_NSÂ \
>> using ::operator| \
>> using ::operator& \
>> using ::operator^ \
>> ... and so on
>
> I don't really like the idea of operators in the global namespace. I
> would rather prefer if the operators were defined in the library's
> namespace, and the enablement was always through the macro. Where the
> macro would not just import the operators for lookup but also "enable"
> them for the given enum.
The library now has a macro-option to prevent importing all operators
into the global
namespace (BOOST_FLAGS_NO_GLOBAL_USING).
Additionally, there are macros to easily import all operators/utility
functions
into a namespace (BOOST_FLAGS_USING_OPERATORS(),
BOOST_FLAGS_USING_UTILITIES()).
I'm not sure what you mean by your last sentence. Do you just ask for a
macro, like
#define BOOST_FLAGS_ENABLE(Enum) \
constexpr inline bool boost_flags_enable(Enum) { return true; } \
BOOST_FLAGS_USING_OPERATORS()
or something else?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk