C++ is perhaps the only language with a strict typing regime that doesn't have any memory safety.
This is ridiculous because safe memory access is more easy to implement, places fewer restrictions on the programmer, and is much more important for writing secure software than strict typing. Unfortunately, it does proscribe pointer manipulation patterns which are popular in C programming, so it was excluded from C++ to align with the "C with classes" marketing.
Right; we're just so used to C/C++ that this seems normal. Here's Eric Lippert telling someone "look, if you check out of a hotel room, your stuff might still be there for a while, right?" Right. Makes sense. (Not blaming Eric Lippert for anything - he didn't design the language, and his explanation is, of course, 100% correct).
What I'd be telling him is this: "You've discovered an EXTREMELY dangerous feature present in C/C++ and almost no other common language. The whole security industry has spent DECADES plugging holes caused by unsafe memory accesses, and it didn't win the battle. The very first internet worm in 1988 used a buffer overrun, and the patch you downloaded yesterday was probably for one of those, too. Of course, unsafe memory access may make a program unreliable, as well as insecure. Be VERY careful."
Of course, I might just need to become more laid-back and mellow...
It wasn't marketing. When C++ took off as a language, such memory safety was a luxury. I've read Stroustrup's Design and Evolution of C++, and I don't think strict memory safety was even considered. Saying it was "excluded" implies that it was considered, when I think the kind of programming they wanted to support - systems programming with minimal performance overhead - precluded it from consideration.
Ada was a contemporary of C++ which had such memory safety. In fact Ada was first standardized long before C++, so the issue wasn't unknown or even obscure when C++ was being developed.
Moreover, there are no run-time performance issues. Memory safety can be verified at compile time provided things like pointer arithmetic are forbidden.
The problem for C++ is that memory safety and C-style pointer manipulation are incompatible.
C++ was marketed as "C with classes." This was a hugely successful marketing move (it helped C++ beat Ada, for one). It wouldn't have worked if all the C programmers keen on picking up "object orientation" had flipped open their C++ book and found that it had "neutered" their pointers though. They wanted to be "OO compliant" by writing "class" instead of "struct" and change nothing else and C++ promised to deliver that.
C++ was based on Stroustrup's early-1970s experience with Simula, where he was able to write a beautiful program (for his thesis research, I think?) that did exactly what he needed, but then discovered that doing the compute run he wanted to do would consume his department's entire computation-time budget on the mainframe. (Apparently 80% of the compute time was being spent in the garbage collector, even after he stopped allocating new objects, which sounds like a straight-up bug in the Simula runtime.) So he rewrote the program in BCPL, which is about like Forth except that it has infix notation and doesn't have metaprogramming.
So, some years later, in 1983, his key consideration in the design of C++ was efficiency — avoiding imposing any unnecessary overhead.
In the interim, although he didn't know this, generational garbage collection and inline method caches had been invented, which probably would have provided enough efficiency that he never would have had to switch to BCPL. (Actually, even a decently implemented early-70s Simula would have been five times faster, and that might have sufficed.)
C/C++ doesn't have this restriction because the hardware doesn't have it. In assembly you can do whatever you want with memory. C was created to give as much access as possible to the hardware, while still providing many of the features of high level languages. It is not the language that is betraying you, it is you that is not clear about what the language can do.
This is ridiculous because safe memory access is more easy to implement, places fewer restrictions on the programmer, and is much more important for writing secure software than strict typing. Unfortunately, it does proscribe pointer manipulation patterns which are popular in C programming, so it was excluded from C++ to align with the "C with classes" marketing.