Re: What is OOP?

On Sun, 2024-12-01 at 17:02 -0500, Richard Damon wrote:

On 12/1/24 12:17 PM, wij wrote:

 
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' and its
restrictions (and restrict by Turing Machine). I think that is generally where
many programming problems from. And, understanding C or assembly is nearly a must
before understanding C++, otherwise, no real meaning, simply put.
 

 
Except that by the rules of pointes in C (and C++) you can not convert a
pointer to one object to a pointer to some other object that isn't
within some defined larger object that the first object was also in.
 
While you can convert any pointer to some interger type, or into a char*
pointer, there is nothing that gaurentes that these somehow correspond
to "raw memory" address in some big raw memory array that you can go
elsewhere with.
 
Yes, currently with most processors, it will just work, but nothing
requires that to work, and in previous segmented architectures, it
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 make
it like a big array (there might be gaps). Human recognition is makeup. 
Although we try hard to make the raw bytes recognizable, the dangerous thing 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 
don't know when 'Segmentation fault' would happen. How do you verify correctness
just by the program 'logic'?