Unfortunately, for C++, thats not true. At least with glibc and libstdc++, if you do not link with pthreads, then shared pointers are not thread-safe. At runtime it will do a symbol lookup for a pthreads symbol, and based off the result, the shared pointer code will either take the atomic or non-atomic path.

I'd much rather it didnt try to be zero-cost and it always used atomics...

▲

TuxSH an hour ago | parent | next [-]

True, but that's a fault of the implementation, which assumes POSIX is the only thing in town & makes questionable optimization choices, rather that of the language itself

(for reference, the person above is referring to what's described here: https://snf.github.io/2019/02/13/shared-ptr-optimization/)

	▲	wyldfire 21 minutes ago \| parent [-]
		> the language itself The "language" is conventionally thought of as the sum of the effects given by the { compiler + runtime libraries }. The "language" often specifies features that are implemented exclusively in target libraries, for example. You're correct to say that they're not "language features" but the two domains share a single label like "C++20" / "C11" - so unless you're designing the toolchain it's not as significant a difference. We're down to ~three compilers: gcc, clang, MSVC and three corresponding C++ libraries.

▲

eddd-ddde an hour ago | parent | prev | next [-]

Why use atomics if you don't need them? There really should just be two different shared pointer types.

▲

woodruffw 3 hours ago | parent | prev [-]

This is, impressively, significantly worse than I realized!