Is an executable in Imperative Programming Language smaller than an executable in Object-Oriented Language?

Well, that's it, usually object-oriented programs have several different calls to Small Methods for passing messages, encapsulation is also a common consequence of the model, not to mention polymorphism and other particularities.

So I know this is quite relative to compilers and the program itself as well as platform, however in a general native code generation strategy, the executable of object-oriented programs is major? If so, or not, could they list why? (regarding programs made in imperative language - like C)

I'm studying programming languages, their paradigms and compilation processes, whatever the step, so they can go pretty low level, like design decisions at compiler and architecture level, preferably ARMv7.

Author: Intruso, 2019-09-08

1 answers

There is no such direct relationship between paradigms and executable size, especially in absolute form. And confuses two different things also unrelated, after all the imperative is certainly a paradigm, and object orientation maybe not, at least some do not consider it so, but if it is is a secondary paradigm, so much so that it is used together with another paradigm, almost always the imperative. Understand that there is the algorithm that is usually imperative (there are some languages that follow the functional, pure almost none, and very rare other paradigm) and General Organization of what is written and assembled data structures and where the algorithms will be, which represents at most a secondary paradigm, if it is paradigm.

An example of so-called Object-Oriented Language has not been cited, but it is almost certain that it is imperative in most of what you do, so there is no such dichotomy. I will consider that it is talking about the procedural use that would also be a secondary paradigm of code organization and not how to write the code itself. Then...

Does a procedurally written application generate a smaller executable than the same object-oriented written application?

The part that takes care of the data structure usually disappears when the code is compiled, this part is only used to help assemble the algorithms. It is important to note that the executable usually only has the algorithms.

You can use metadata to give more wealth to the executable and facilitate reflection activities, so using a reflexive secondary paradigm will be more responsible for the executable growing than object orientation that does not necessarily need to be extra code generator.

A lot determines the size of the executable

Other ways of programming, architecture, and a number of influences will determine much more the size of the code.

This business of imperative language and language-oriented object is something else wrong. If these are programming styles you can use one or the other in any language, then this way of looking at languages is wrong. You can program object-oriented in C , so the comparison got harder.

Is even worse because the size of the executable is often determined by the size of the runtime and standard language library, as well as how this is used. For example, C almost always does not need a large use in the executable because its library is already in the operating system and will be loaded dynamically, so it seems that it is tiny and not quite like that. Of course the total sum is still small because C is minimalist, but this has nothing to do with Paradigm. And although it's not part of the executable the runtime is there Whole even if you don't use all of it, in code linked statically can save by taking only what you need to use (more or less), but then the comparison is fairer with languages that cannot rely on the runtime in the operating system and that has some advantages as well.

Comparing similar languages

So we can compare C with C++ which are very close languages, something even unique to happen. C++ has an always larger executable, even if you make 100% use of procedural, and although the difference is small, it is larger even if you make use of only C code in the C++compiler. Realized that do you have other things that influence? But if you observe the use of the same written procedural and object-oriented code, the second one will be a little larger, at least in my experience. I do not say that it is not possible to stay the same or until the OO becomes smaller in some circumstances, is that in practice the way of programming becomes another.

Actually having more Small Methods Helps the Code Get Bigger. But if the compiler is good it will linearize most of them, but certainly not all, and this minimizes the problem.

If you use a polymorphic form in procedural it can take up the same or more space than in OO. Using polymorphism can in some cases save space than an algorithm that solves in runtime something that a language can solve in compilation (some can't do this), but it also has polymorphism that is solved at compile time and increases the code size well (but this is meta programming and not code orientation). object).

Other languages are more difficult to compare because they have several other commitments, so I finish as I started, this comparison made fairly does not make sense.

And the size of the executable is quite unimportant.

I think to go beyond this is to escape the focus and if you need to know more, now you have subsidies for new questions, not least because it could become a chapter of a book.

 5
Author: Maniero, 2020-06-11 14:45:34