OSNews

C++ doesn't natively support synchronization primitives. Ok, so now you whine.

I ask you this, though: what would you have C++ compiler writers do when the underlying hardware/OS doesn't support some particular type of primitive natively? Have them write something completely new that needs to be run as some sort of kernel module or a driver?

Any threading primitives that aren't truly...primitive... tend to lock a computer programming language down to a single OS or a subset of OS platforms: this is NOT the goal of the C++ standards body, as the C++ language has as one of its design goals that of being something that can be used to write things like an OS, or, for that matter, just write down to hardware very directly in an embedded system where there's no real OS to speak of, but just ISR's and a processing loop. As it is, C++ already has a fairly large runtime library that needs to be taken along with every application built: this may be linked in statically, or linked in dynamically. By making the language larger and less OS-independent as you would have it do, you'd end up making it less and less capable of fulfilling its design goals and target usage.

If you want languages with built-in threading primitives built-in to the language itself, you need to be willing to put up and go and implement a new language from the start with that in mind, or you need to just accept such things as user libraries, so that not all poor saps have to carry along excess baggage when they don't need it. After all, while a large portion of the human population may be completely unaware of it, the number of CPUs used by machines people think of as any sort of personal computer is dwarfed by the number of processors in embedded applications that need such low-level languages as C/C++. C++ is complex enough as a language as it was, and as it is becoming, and is very powerful, too: there's no overriding (pardon the pun!) need to overload things even more by going out of your way to make it bigger when such things can more practically (don't take along excess overhead if not needed) do it in external libraries.