$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [Atomic] Rationale for preventing copy construction/assignment?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2013-05-29 23:49:08
AMDG
On 05/29/2013 01:22 PM, 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>?
>
How would you make it sequentially consistent
without using a mutex?
In Christ,
Steven Watanabe