Perhaps the useful angle on this isn't really about security, but instead
that it's misleading when resources for learning C++ say "private data
can't be changed by other code". In a way that's the purpose of "private",
but it's more accurate to say "C++ doesn't allow changing values via a
private variable in other code" and "'private' is a tool for stating the
intent of a variable in a way that compilers will often enforce".

In the C language, "const" is a tool for stating the intent of some data,
but in many cases code can just remove that "const" with a pointer cast and
modify the data anyway. It's useful because it makes it harder to
accidentally do what some other code (by someone else or yourself) advised
not to do. Really, unless you're writing assembly code or direct byte
instructions, *every* language feature in a language like C, C++, Java,
Rust, etc. is a tool of this sort, while in fact you can still do anything
the OS and hardware allow.

There is another approach to programming languages with strictly defined
limits on what code can and can't do. Lua is one example, often used in
games to allow users to write code and still know their code won't cause
crashes or do naughty things. That requires a separate interpretation layer
at runtime between the OS and the Lua code, slowing down some things, so
it's not appropriate for, say, complicated mathematical computations. C++
and its kin have a philosophy of staying "close to the hardware", or "make
all things possible and common things easy". These language categories are
separate use cases, both useful per situation.

>From this point of view, all languages are safe then.
>
>
I'd instead say no languages are safe, or safety is just not a feature of
high-level programming languages. As in life, "safety" is relative, not a
binary yes or no, and there's no such thing as completely safe.

-- Andrew Schepler