|
Boost : |
From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2020-06-03 12:44:57
> On 2. Jun 2020, at 17:37, Andrey Semashev via Boost <boost_at_[hidden]> wrote:
>
> On 2020-06-02 17:28, Hans Dembinski via Boost wrote:
>>> On 2. Jun 2020, at 11:21, Alexander Grund via Boost <boost_at_[hidden]> wrote:
>>>
>>>
>>>>> boost::interprocess::atomic.
>>>>
>>>> That name cannot be used in Boost.Atomic as it is reserved for Boost.Interprocess.
>>>>
>>>> Atomics that are lock-free can already be used for inter-process communication, so a hypothetical boost::interprocess::atomic would largely duplicate boost::atomic. However, I'm open to the idea, if it is significantly different from boost::atomic.
>>>
>>> The obvious solution then is to use boost::atomic::interprocess ;-)
>> ... I was going to suggest the same :)
>
> The problem with this is that the resulting name will be long and have the potential of name clash with Boost.Interprocess.
>
> Boost.Atomic types are currently defined in namespace boost::atomics and then imported into namespace boost (so that people can use boost::atomic<int> instead of boost::atomics::atomic<int>). Adding namespace boost::atomics::interprocess would make it impossible to import it into namespace boost as it would conflict with Boost.Interprocess. So people will have to spell boost::atomics::interprocess::atomic<int>, which is unfortunate.
>
> There is an alternative to name the type differently, e.g. boost::atomics::interprocess_atomic<int> or boost::atomics::pshared_atomic<int>, though I'm not sure I like it either. Or use a different name for the nested namespace instead of interprocess (ipc? other suggestions?).
Makes sense. I guess we all agree that redundancy in names/namespaces is bad. If the hypothetical namespace boost::atomics::interprocess is going to contains only a single type anyway, then boost::atomics::interprocess_atomic<int> seems like a good compromise to me, or maybe boost::atomics::ipc_atomic<int> if you want it shorter.
Best regards,
Hans
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk