Re: [boost] [Atomic] Rationale for preventing copy construction/assignment?

Subject: Re: [boost] [Atomic] Rationale for preventing copy construction/assignment?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-05-29 23:41:23

On Wednesday 29 May 2013 13:22:09 Collin Dauphinee wrote:
> I've recently noticed that boost::atomic<T> prevents assignment from
> boost::atomic<T>, as well as copy construction. I'm having trouble
> understanding why this decision was made, as it makes boost::atomic<T> (and
> classes with a boost::atomic<T> member) very hard to store in containers,
> and I can't immediately see any safety issues that would be caused by
> allowing copy operations.
> 
> What is the rationale for not allowing assignment or copy construction from
> another boost::atomic<T>?

Boost.Atomic tries to follow the standard interface closely, and it doesn't 
allow copying or assignment.

Copying can be emulated if you explicitly cast or load the source atomic value 
and initialize the target with it. With containers, you can use emplace() to 
insert atomics.