Re:Data-oriented design or why you might shoot yourself in t...
by corty on Monday June 28, 2021 @02:37PM
(#27665808)
Well then, C++ doesn't have encapsulation, therefore C++ isn't OO. Hell, even Java isn't OO if you allow JNI.
Re:Data-oriented design or why you might shoot yourself in t...
by rsj_hn on Monday June 28, 2021 @09:51PM
(#27670748)
I don't want to get into a debate defining what language is OO and what is not. My point was rebutting the notion that C has private data structures by pointing out only languages in which memory is managed by the runtime (e.g. VM) can offer isolation guarantees. Attempts to switch the topic to OS level memory protections are not really what we're talking about here, as the OS doesn't provide language level protections. So yes, if your code leaves the VM then you lose those VM protections.
Re:Data-oriented design or why you might shoot yourself in t...
by bccdee on Monday June 28, 2021 @10:18PM
(#27670950)
> I don't want to get into a debate defining what language is OO and what is not
I mean, that is the discussion we were having. We weren't talking about language VMs.
Re:Data-oriented design or why you might shoot yourself in t...
by rsj_hn on Thursday July 01, 2021 @01:42PM
(#27701968)
I was replying to a statement that C had isolation and I pointed out that it didn't. The response was a non-sequitur: "So then even C++ isn't OO", and I responded that the question is not whether C++ is OO but whether it's memory is managed. Not sure how any of this is hard to follow or why these arguments should trip you up.
Re:Data-oriented design or why you might shoot yourself in t...
by bccdee on Friday July 02, 2021 @06:24PM
(#27717676)
The statement was specifically that C had encapsulation, within the context of a discussion about whether OOP should be defined as "encapsulation, abstraction, polymorphism, and inheritance."
You interpreted that as meaning memory isolation for some reason (even though plenty of clearly-OOP languages do not implement that), and when someone asked you how that definition of encapsulation squared with the fact that C++ is generally considered object-oriented, you said you didn't want to have that conversation.
It's not hard to follow and it didn't trip anyone up; you just changed the subject out of nowhere and for no discernible reason by injecting a contextually-inappropriate definition of "encapsulation."
Re:Data-oriented design or why you might shoot yourself in t...
by bccdee on Monday June 28, 2021 @04:02PM
(#27667137)
If we're talking about making guarantees about blocking the programmer's ability to modify parts of the address space, we're no longer discussing programming paradigms. We're discussing security proofs. The MMU does not play a core role in object-oriented programming.
Re:Data-oriented design or why you might shoot yourself in t...
by corty on Monday June 28, 2021 @04:37PM
(#27667735)
Historically, this is not entirely correct. Segmented MMUs (as opposed to the more common, currently used concept of paged MMUs) were intended to provide the hardware support for the protection levels and the data/code mixture in OOP. I.e. each object would have executable, readable, r/w and inaccessible parts. Protected by the MMU, depending on the currently accessing context, that is, a subclass, friend class, other class, etc. But creating a segment descriptor for each object or even just each class was, of course, far too expensive in the end.
Re:Data-oriented design or why you might shoot yourself in t...
by bccdee on Monday June 28, 2021 @10:15PM
(#27670924)
That's actually really interesting, I hadn't heard of that.
Re:Data-oriented design or why you might shoot yourself in t...
by rsj_hn on Monday June 28, 2021 @09:49PM
(#27670727)
We're not talking about the programmer doing something, but about the code doing something, which is absolutely all about security proofs. And while the OS protects an address space, the OO runtime protects memory within that runtime, so a private variable isn't available to code running outside the class while the same cannot be said for C code. That's the benefit of offloading memory management in interpreted languages.
No language that supports memory access for the entire address space of the currently running program can ever support something like encapsulation: you can pass pointers to objects and functions outside the currently running module, or you could somehow derive this info from outside the module and so access functions and objects that were not declared in header files. Thus the language cannot give you the isolation guarantees that memory managed languages can. What it can do, is put up some roadblocks or barriers that require effort to cross. But there is a big difference between correctness guarantees and roadblocks.
There really is a qualitative change when you are working in a memory managed language as that allows the language to assign fine grained control over which memory addresses are available to which data structures, which is something that you cannot do with C.