I misremembered...

So I just went and look this up the C++14 standard, or at least the nNvember draft is 1368 pages and the Ruby ISO standard is 313. I was off by a fair amount.

But this made my point more extreme. C++ has mauch smaller feature list than Ruby and the spec is more 4x the size C++ is much more specific and precise. Ruby and many other languages will use the behavior of some de-facto implementation as their standard.

Is C++ really better specified? Some languages use "the implementation is the spec" and that's bad, sure (though I'd argue it's less bad than "programs that worked on previous versions of the compiler will contain memory safety vulnerabilities on newer versions of the compiler", which is the end result of C++'s approach to undefined behaviour). But compare to e.g. Java, which has a (shorter!) spec with multiple implementations, including a well-specified memory model in the presence of threads (which weren't even specified at all by C++ until recently), and more importantly actually defines behaviour rather than specifying very carefully the wide range of conditions in which the compiler is permitted to arbitrarily break your code.

Memory is specifically hard one for C++ because it tries not to put a layer between the coder and the underlying hardware. Much of the memory model must be implementation defined.

It wasn't that long ago that we had different pointer for small fast memory and large slow memory, back when more that 64k was a real big deal. Kind of like how now video memory is a real big deal. Now we have a bunch of weird C APIs for putting things there (I presume these can be accessed from JNI or something similar), but these are temporary ugly hacks.

When video ram becomes a more common thing to refer to specifically, what will that look like in Java? That weird memory that C++ has is ready, because it has done exactly this in the past a few times. I am also looking forward to C++17 and its newer way to run std algorithms on heterogeneous executors (like GPUs).