To elaborate on this (because I think it's interesting)...

The point of private/protected/public is for a library maintainer to tell
consumers "here is an interface that I promise" versus the other parts that
are required to implement it.

In certain languages, like C#, you can use reflection to iterate over the
private (and protected) fields and access them directly. That is a
supported usage of the language.

The catch is that, if the upstream developer changes their private
implementation, then the original developer can shrug at you if their
change broke your downstream code. If they break their public interface
within a supported version, however, then you can file a bug because they
broke their promise.

Private/protected/public *isolates responsibility*. It has nothing to do
with security in C++ or other languages.


On 2025-02-17 09:15, Andrey Semashev via Std-Discussion wrote:

On 2/17/25 12:33, Amit via Std-Discussion wrote:

C++ language has a big security hole. You can change the values of the
private member variables directly by getting the pointer to the
object. So, private member variables are actually not private, they
are public.

Others have already said about UB, I just wanted to add that member
access specifiers are not (and never were) a security measure. As such,
even if you could have a legal way of accessing a private member, this
would still not constitute a security breach.