On segunda-feira, 3 de dezembro de 2012 18.08.01, Francisco Lopes wrote: > Can you point out where in the standard brace assignment initialization is > not supposed to invoke a copy constructor? Because from what I've pointed, > I only see this case, and so I see both the compiler not working as > expected as both the qt and all this library code as ill-formed.
That's not my point. The standard leaves ATOMIC_VAR_INIT as an implementation-
defined value, so long as this works:
atomic<int> v = ATOMIC_VAR_INIT(1);
I then pointed out that libc++'s own std::atomic has the deleted copy
constructor and assignment operator, as required, and their ATOMIC_VAR_INIT is
using brace initialisation.
If you're right and brace initialisation is not permitted, then they'll have
to fix ATOMIC_VAR_INIT in their implementation. But given that their
implementation as well as GCC's uses brace initialisation to call the int
constructor, it seems to me it should be permitted.
An alternative I can see is to add an intermediate type such as
template <typename T> struct atomic_initializer
{
constexpr atomic_initializer(T t) : value(t) {}
T value;
};
template <typename T>
atomic_initializer<T> atomic_initializer_helper(T v)
{ return atomic_initializer<T>(v); }
And add a constructor that does allow copying from this type:
template <typename X>
constexpr atomic(atomic_initializer<X> i) noexcept;
template <typename X>
T operator=(atomic_initializer<T> i) noexcept;
And finally change the macro to use that:
#define ATOMIC_VAR_INIT(v) (atomic_initializer_helper(v))
However, I'm not sure that we wouldn't end up at exactly the same problem
we're at right now due to the deleted copy constructor.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
