I want to use an std::atomic_int variable. In my code, I have:
#include <atomic>
std::atomic_int stop = 0;
int main()
{
// Do something
}
And this gives me a compile error:
use of deleted function 'std::__atomic_base<_IntTp>::__atomic_base(const std::__atomic_base<_IntTp>&) [with _ITp = int]'
std::atomic_int stop = 0;
^
Any idea on what's going on?
Your code is attempting to construct a temporary std::atomic_int on the RHS, then use the std::atomic_int copy constructor (which is deleted) to initialise stop, like so:
std::atomic_int stop = std::atomic_int(0);
That's because copy-initialisation, as you are performing here, is not quite equivalent to other kinds of initialisation.
[C++11: 8.5/16]:The semantics of initializers are as follows [..]If the initializer is a (non-parenthesized) braced-init-list, the object or reference is list-initialized (8.5.4).
(this allows for option 3, at the end of this answer)
[..]
If the destination type is a (possibly cv-qualified) class type:
- If the initialization is direct-initialization, or if it is copy-initialization where the cv-unqualified version of the source type is the same class as, or a derived class of, the class of the destination, constructors are considered. The applicable constructors are enumerated (13.3.1.3), and the best one is chosen through overload resolution (13.3). The constructor so selected is called to initialize the object, with the initializer expression or expression-list as its argument(s). If no constructor applies, or the overload resolution is ambiguous, the initialization is ill-formed.
(this almost describes your code but not quite; the key here is that, perhaps contrary to intuition, std::atomic_int's constructors are not considered at all in your case!)
- Otherwise (i.e., for the remaining copy-initialization cases), user-defined conversion sequences that can convert from the source type to the destination type or (when a conversion function is used) to a derived class thereof are enumerated as described in 13.3.1.4, and the best one is chosen through overload resolution (13.3). If the conversion cannot be done or is ambiguous, the initialization is ill-formed. The function selected is called with the initializer expression as its argument; if the function is a constructor, the call initializes a temporary of the cv-unqualified version of the destination type. The temporary is a prvalue. The result of the call (which is the temporary for the constructor case) is then used to direct-initialize, according to the rules above, the object that is the destination of the copy-initialization. In certain cases, an implementation is permitted to eliminate the copying inherent in this direct-initialization by constructing the intermediate result directly into the object being initialized; see 12.2, 12.8.
(this is your scenario; so, although the copy can be elided, it still must be possible)
- [..]
Here's the fix, anyway; use direct-initialisation or list-initialisation:
std::atomic_int stop(0); // option 1
std::atomic_int stop{0}; // option 2
std::atomic_int stop = {0}; // option 3
T a = x; creates a temporary T constructed from x, and then initialises a from that temporary. Copy elision may eliminate the temporary, but the copy constructor must nonetheless be available. –
Majka std::atomic_int stop = {0};. This is copy-initialization, but copy-initialization using a braced-init-list performs copy-list-initialization, which does not involve temporaries (in this case). –
Majka -std=gnu++14 doesn't make it legal, so it was something new in C++17. –
Demerol The problem is that
std::atomic_int stop = 0;
... is copy-initialization. This means that you're not directly initializing the stop to a value of zero, but rather, you're creating a temporary object and then calling the copy constructor of std::atomic_int, as if by:
std::atomic_int temporary(0); // this would be okay
std::atomic_int stop = temporary; // this isn't (use of deleted copy constructor)
In C++11, the compiler is allowed to optimize this to not call the copy constructor, but only if the type is copyable or movable. std::atomic isn't. If it isn't, then this code is ill-formed.
Note that your code is perfectly valid in C++17. This is due to mandatory copy elision. It is guaranteed that
std::atomic_int stop = 0;
... doesn't call the copy or move constructor at all, so it is valid.
On a side note, the prior restrictions can be annoying in projects that prefer the use of auto:
auto m = std::mutex{}; // invalid in C++14, valid in C++17
In my case I had de following errors (Examples):
• ‘std::literals’ has not been declared
using namespace std::literals::string_literals;
• “Use of deleted function” error with std::random_device{}
std::random_device device = std::random_device{}
Check what is your selected C++ Standard. In my case on debug mode I had selected -std=c++17, ALL OK. But on Release mode I had selected -std:c++11, tons of errors.
Update Tested on Clion Windows 2018.3 with remote Linux compile.
Using -std=c++11
Using -std=c++17
C ++ is an evolving standard: after 2003 there were 2011 (C ++ 11), then 2014 (C ++ 14) and now we have 2017 (C ++ 17) and we are working for 2020 (C ++ 20) . Many things are changing, they are deprecated, other features are new. If you want the latest update, you should use the most recent standard, if your software has code that may be deprecated then you have to use the standard with which it was created.
std::atomic_int? –
Ticktacktoe = 0. The answer reads like you're saying you had similar "use of deleted function" errors from std::random_device{} . Nowhere (except in those small hard-to-read pictures of your whole dev-env) does this answer actually say that C++17 makes the code in the question compile. (That is the case, though. godbolt.org/z/uNswJL. Even -std=gnu++14 doesn't make it legal, so it was something new in C++17.) –
Demerol © 2022 - 2024 — McMap. All rights reserved.
std::atomic_int stop = std::atomic_int(0);, and that will not work as the copy-constructor is deleted. Instead try to do direct initialization, likestd::atomic_int stop{0};. – Farinaceous