Re: [boost] [atomic] Bikeshedding over address-free waiting/notifying operation names

On 2. Jun 2020, at 17:37, Andrey Semashev via Boost wrote:

On 2020-06-02 17:28, Hans Dembinski via Boost wrote:

...

...

On 2. Jun 2020, at 11:21, Alexander Grund via Boost 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