Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: wij <wyniijj5@gmail.com>
Newsgroups: comp.lang.c++
Subject: Re: What is OOP?
Date: Mon, 02 Dec 2024 08:57:41 +0800
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <253c0b3fe3ac8ea661af3347f93529bd0f03f3e2.camel@gmail.com>
References: <d8a5a0d563f0b9b78b34711d12d4975a7941f53a.camel@gmail.com>
	 <3a72f45ce7a77c6272e207f009ba09aece96f8df@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Injection-Date: Mon, 02 Dec 2024 01:57:42 +0100 (CET)
Injection-Info: dont-email.me; posting-host="4577dd8d25eca687854d0e4ae5cd6643";
	logging-data="3018172"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19cIk4p/TaK3TeqFsgtgxdp"
User-Agent: Evolution 3.50.2 (3.50.2-1.fc39)
Cancel-Lock: sha1:3hSzzfah71R+FnfvTE3vQELysNM=
In-Reply-To: <3a72f45ce7a77c6272e207f009ba09aece96f8df@i2pn2.org>
Bytes: 3029

On Sun, 2024-12-01 at 17:02 -0500, Richard Damon wrote:
> On 12/1/24 12:17 PM, wij wrote:
> >=20
> > OTOH, in C/C++, every memory objects/function has address, the language=
 cannot
> > pretend it is not actually dealing with a large array of raw 'bytes' an=
d its
> > restrictions (and restrict by Turing Machine). I think that is generall=
y where
> > many programming problems from. And, understanding C or assembly is nea=
rly a must
> > before understanding C++, otherwise, no real meaning, simply put.
> >=20
>=20
> Except that by the rules of pointes in C (and C++) you can not convert a=
=20
> pointer to one object to a pointer to some other object that isn't=20
> within some defined larger object that the first object was also in.
>=20
> While you can convert any pointer to some interger type, or into a char*=
=20
> pointer, there is nothing that gaurentes that these somehow correspond=
=20
> to "raw memory" address in some big raw memory array that you can go=20
> elsewhere with.
>=20
> Yes, currently with most processors, it will just work, but nothing=20
> requires that to work, and in previous segmented architectures, it=20
> simply wasn't true.

My point is that object is eventually a piece of consecutive 'raw' bytes in=
 the
'big array'. We don't know how hardware might actully be, but C/C++ will ma=
ke=20
it like a big array (there might be gaps). Human recognition is makeup. =
=20
Although we try hard to make the raw bytes recognizable, the dangerous thin=
g is
pretending it is not or unaware what it is when programming in C/C++.
The easiest proof is using debugger. Sounds easy? but not, as it appears.

E.g. if the programer doesn't understand what the stack is (C++ pretty much
avoid talking about it), his/her C/C++ program would be suspicious because =
we=C2=A0
don't know when 'Segmentation fault' would happen. How do you verify correc=
tness
just by the program 'logic'?