The existence of CWG 1885 seems to imply that until C++14, the following code was not guaranteed to be threadsafe
std::string get_string()
{
std::unique_lock<std::mutex> lock(some_shared_mutex);
return some_shared_string;
}
because the ordering of events on the exit of the function was not guaranteed - e.g. lock could be destroyed before the temporary to be returned is copy-initialized from some_shared_string, leading to a race condition.
This seems incredibly unlikely to be an issue in practice - one of the main advantages of unique_lock is that you're supposed to be able to do things like this, and I'd be a bit surprised to find out that an implementation didn't guarantee this even though the standard doesn't.
So my question(s)
- I'm not familiar with how C++ defect reports get retroactively applied, but it seems like since this is "CD4" status, that means it retroactively applies to C++14, but not 11; is that correct? The defect reports list on cppreference appears to say this also - 1579 applies to C++11, but 1885 applies to C++14
- Is this a practical concern? It seems like it'd be a bug in compilers supporting C++11 if they don't guarantee the expected ordering. Even though it could technically follow the standard without doing so, I can't see why anyone would want that.
- What about with really old compilers? If this was an issue at one point and got retroactively applied to C++11 by a specific implementation, how would I figure out which version of a compiler fixed it? I'm stuck with a toolchain that's still using GCC 4.8 - I don't see any bug report in the GCC bugzilla about this, but I can't find any confirmation that's it's not a potential issue either.