OOP versus runtime procedures

Question

I have a very simple question that I cannot find anywhere on the Internet.

So my question is that in procedural programming, the code is in a section of code that goes into the read-only memory area. Variables are either on the stack or on the heap.

But OOP says the object is created in memory. So, does this mean that even functions are written to the R / W memory area?

And should Os really have support for OOP firmware? For example, if OS doesent is allowed to read instructions outside the Read Only section. Thank you

Answer 1

As a rule, both OOP and procedural programming are abstractions that exist only at the source code level. When a program is compiled into executable machine code, these abstractions cease to exist. Thus, regardless of whether a particular OOP language is procedural, it has nothing to do with the memory areas it uses, or when instructions are placed at run time.

The OS itself usually does not know or care about whether a particular executable was written in OOP or a procedural language. It is only relevant that the executable uses binary operating codes compatible with its own set of commands, and that the executable has an ABI (binary interface) that it understands.

Answer 2

This is a good question.

While an object represents functions and data that are theoretically located in the same place, most implementations share it. The way you do this is that the code is split and stored in the RO segment. Then, the object in the RW area has the ability to refer to this code in the RO area. The combination of code and data is used conceptually only by the human programmer and type controller to ensure that you do not violate the rules and principles.

Typically, Java / C # is similar to a language, so each object has a tag identifying the type of object. The object itself is simply a structure containing all the fields laid out in a given order. You can then use this tag to search for the function that you want to call in the RO zone. The function in the RO area is changed to get an additional parameter called this or "I" through which the contents of the specified object can be reached. When a method needs to refer to fields, it knows a predefined order, so it can perform this correlation. Note that some tricks are needed to solve inheritance, but this is the essence of the idea.

A Python / Ruby language usually makes the object a hash table, where the method is a pointer to code in the RO area (provided that the language is compiled and does not run through the bytecode interpreter). The function call is made by searching the contents of the hash table and the subsequent code pointer. Fields are also viewed in the same hash table.

Given these basics, most implementations do tricks to avoid where the pointer is used to find the function to call. They try to figure out and narrow down a possible call to one function. Then they can replace the search with a direct call to the right function, a much faster solution.

tl version; dr: language semantics considers fields and methods as part of an object. The implementation divided them into RO and RW segments. As such, OS support is not required.

Answer 3

OOP does not talk about this. I don’t know where you read it, if you add a quote that helps.

Objects are variables, so what you know about variables is true for objects. In languages ​​such as C # (.net framework), objects can only be stored on the heap because they are so-called reference types. In C ++, they can live anywhere.

But OOP says the object is created in memory. So, does this mean that even functions are written to the R / W memory area?

From this, I came to the conclusion that you think functions are objects. This is far from true for every OOP language. This is from functional languages, where functions are first class objects. Functions in most cases are immutable and are placed in read-only sections.

General operating systems, such as Windows, Linux, and MacOsx, are not aware of objects. This is a purely software concept..net framework and java vm provide a level of abstraction. They are runtimes that have built-in support for objects.