Opened 10 years ago
Closed 7 years ago
#8057 closed Feature Requests (fixed)
Add constexpr + noexcept for atomic
Reported by: | viboes | Owned by: | timblechmann |
---|---|---|---|
Milestone: | Boost 1.54.0 | Component: | atomic |
Version: | Boost 1.53.0 | Severity: | Problem |
Keywords: | Cc: | Andrey.Semashev@… |
Description
Make boost::atomic behave as C++11 concerning constexpr and noexcept.
In particular
atomic() noexcept = default; constexpr atomic(T) noexcept;
Note that the constructor from T is not explicit.
Attachments (1)
Change History (11)
comment:1 by , 10 years ago
Summary: | Add constexpre + noexcept fro atomic → Add constexpr + noexcept fro atomic |
---|
comment:2 by , 10 years ago
Summary: | Add constexpr + noexcept fro atomic → Add constexpr + noexcept for atomic |
---|
comment:3 by , 10 years ago
Milestone: | To Be Determined → Boost 1.54.0 |
---|
comment:4 by , 10 years ago
Hi,
The following patch worked for me.
svn diff boost/atomic Index: boost/atomic/detail/base.hpp =================================================================== --- boost/atomic/detail/base.hpp (revision 82860) +++ boost/atomic/detail/base.hpp (working copy) @@ -143,7 +143,7 @@ typedef T value_type; typedef lockpool::scoped_lock guard_type; public: - base_atomic(void) {} + BOOST_CONSTEXPR base_atomic(void) {} explicit base_atomic(const value_type & v) { @@ -230,8 +230,8 @@ typedef T difference_type; typedef lockpool::scoped_lock guard_type; public: - explicit base_atomic(value_type v) : v_(v) {} - base_atomic(void) {} + explicit BOOST_CONSTEXPR base_atomic(value_type v) : v_(v) {} + BOOST_CONSTEXPR base_atomic(void) {} void store(value_type v, memory_order /*order*/ = memory_order_seq_cst) volatile Index: boost/atomic/atomic.hpp =================================================================== --- boost/atomic/atomic.hpp (revision 82860) +++ boost/atomic/atomic.hpp (working copy) @@ -88,8 +88,8 @@ typedef T value_type; typedef atomics::detail::base_atomic<T, typename atomics::detail::classify<T>::type, atomics::detail::storage_size_of<T>::value, boost::is_signed<T>::value > super; public: - atomic(void) : super() {} - explicit atomic(const value_type & v) : super(v) {} + BOOST_CONSTEXPR atomic(void) : super() {} + explicit BOOST_CONSTEXPR atomic(const value_type & v) : super(v) {} atomic & operator=(value_type v) volatile {
But I suspect that we need to specialize boost::atomic<integral>.
BTW, why the construtor needs a memcpy?
explicit base_atomic(const value_type & v) { memcpy(&v_, &v, sizeof(value_type)); }
comment:5 by , 10 years ago
i've started working on a patch, but i'm not sure how complete it is.
- not sure about keeping the explicit. according to the standard, there is no explicit ctor.
- also the standard says: 'call by value', not 'call by const-reference'
- regarding the memcpy, i think it is better to cast to the storage type and let the compiler do the copying. memcpy might be slightly better as it probably has relaxed aliasing constraints (not sure if the compiler is smart enough that object and member are different objects). why memcpy was used in the first place, no idea ... the original author might know
comment:6 by , 10 years ago
Sorry, the preceding patch didn't worked at all. See attached patch that works for
static BOOST_CONSTEXPR boost::atomic<int> x(1);
by , 10 years ago
Attachment: | 8057.patch added |
---|
comment:8 by , 10 years ago
Cc: | added |
---|
The memcpy is needed when the value type is a struct. The struct size may not match exactly the storage_type (e.g. struct s { char a[ 3 ]; };), so we have to zero-initialize the storage first and then copy the struct into it with memcpy. This also takes care of the alignment issue as a side effect.
comment:9 by , 8 years ago
Should we close this ticket? In the latest library version everything is marked noexcept and constexpr (except for user-defined types and pointers).
comment:10 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
hm, seems that the codebase will require some refactoring to match the c++11 API. will have a look, but it might take me some time.