Ambitious ideas !!! - page 4
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Calm down.
Why is it nonsense? Just calculate how many pointers it takes to get to the right data or function.
If you certainly know how to count. :)
Will you calm down? what to go through? when you create a new instance of a class - i.e. a variable of class type, it creates a duplicate of the relation table and that's it
Access to data, both in class and in usual variable is the same in speed, all descriptive measures on division of access rights inside classes (privat, public) - all this is at compiler level, compiled code works only with physical memory cells
Well, let's assume that there will be a "complex dynamic class" which is cunningly spawned on the fly from other cunningly spawned classes. So what? After all, everything will be computed by a specific function. So, was it really worth building a garden for such circus tricks?
Is the disease progressing? You have been told several times, OOP frees the programmer from routine actions of data preparation, from control over the contents of data and it is up to the programmer how you implement methods within the class or call third-party functions
OOP is also a thing of the past. The current trend is hardware-oriented programming, which is mostly in C, for example CUDA. With release of processors with GPU this will be further enhanced. Processor companies are planning to stop releasing only universal processor cores.
Here I am not competent, and in your mouth this information does not seem credible
SZZY: why I write you, don't write nonsense at technical forums, share your knowledge and if you don't know something, ask me.
will you calm down? what to go through? when you create a new instance of a class - i.e. a variable of class type, it creates a duplicate of the relation table and that's it
access to data, whether in a class or an ordinary variable, is the same in terms of speed, all descriptive measures to separate access rights within classes (privat, public) are all at compiler level, compiled code works only with physical memory cells
Then here is a question for an expert. There is a class that consists of three dynamic arrays (size at compile time is unknown).
Now please calculate and compare number of operations for access to arbitrary static array and dynamic array inside the class.
I am not competent here, and in your mouth this information does not seem credible
What does the logic of the program have to do with the presentation of data? These things are not connected at all.
The program logic is arithmetic operations on any input data, while the data representation is just data in one format or another.
And by definition it's impossible to reduce program code with OOP since there appear external pointers to objects to access internal data (functions and variables) instead of direct access. But since calculation of pointers and memory reference is a very slow operation, performance slows down accordingly.
Developing OOP applications is not the same as developing class libraries. Strictly speaking, a library developer should not _at all_ care what their library will be used for by those who write the application programs themselves. For example: a hammer maker does not care at all how you use his product - for hammering nails or cracking nuts. His job is to create a tool. Also in OOP classes are tools to solve a certain range of tasks, usually very wide and not always clearly defined (who knows, maybe you use a hammer to kill cockroaches?)
Once again, to solve the simplest tasks you don't need OOP. But on the other hand, you do not think that everyone who wants to hammer a nail has to make a hammer for himself, do you?
Of course, you can argue that we already have function libraries, why do we need more classes? But in this case you deprive yourself of conveniences provided by inheritance mechanisms, type extensions, overloading etc. Roughly speaking, you can screw a homemade motor to a hammer and make it work your way, but you don't have to understand the hammer mechanism; all you need to know is that it can be used to hammer nails.
So, believe me, OOP really does make life easier for those programmers who write applications. Another thing is that the capabilities of MQL5 libraries are still very limited, but it's a matter of time, and the library developers will take care of it (although of course they can be - but are not required to be - the same people). With well-developed system of class libraries, it is enough for a user-programmer to write one or two lines like "1. program, here is data" "2. program, count", almost without asking a question how it works in details. This cannot be achieved in structure-oriented programming.
It seems to me that your bias against OOP is the result of the fact that you either haven't encountered sufficiently complex tasks, or you simply don't want to do it due to laziness or some other reason. I'd say that for nothing. However, the master is the master.
Here is an expert's question. There is a class that consists of three dynamic arrays (size at compile time is unknown).
Now please calculate and compare number of operations to access arbitrary static array and dynamic array inside class.
What do classes have to do with it? You work with dynamic or static arrays, and it doesn't matter where you use dynamic arrays - in a class or just in a variable.
The fact that working with dynamic arrays takes a bit longer is "obvious" - there is a control for array overruns and the dynamic memory allocation manager will often be called
alsu:
1. But in that case, you deprive yourself of the convenience afforded by the mechanisms of inheritance, type extensions, overloading, etc. Roughly speaking, you can bolt a handmade motor to a hammer and make it work your way, but you don't have to understand the mechanics of the hammer; all you need to know is that you can hammer nails with it.
2. With a well-developed system of class libraries, it's enough for a user-programmer to write one or two lines like "1. program, here's the data" "2. program, count" in a program, almost without asking how it works in detail. This cannot be achieved in structure-oriented programming.
1. In RPP, you also have to deal with the classes - what exactly they do. Just as if it were a function of some kind. But with classes it is harder to trace the whole chain, so generally more time is spent on studying their structure, at the same level of functionality.
2. In structure-oriented programming, you can also organise such actions without any problems, without having to go into details that someone has already gone into before.
What do classes have to do with it? It's all about working with dynamic or static arrays, and it doesn't matter where you use dynamic arrays - in a class or just in a variable
Ok, I'll ask a simpler question. Compare the number of operations when accessing a variable of a one-dimensional and a two-dimensional array.
And now you're going to argue that there's almost no difference?
Ok, then I'll ask a simpler question. Compare the number of operations when accessing a variable in a one-dimensional and a two-dimensional array.
Are you going to claim that there is almost no difference?
Is this also an OOP question?
If no, then: if the array is static - then there will be no difference in performance when you address a one-dimensional array, as well as a two-dimensional one, because multidimensional array data is stored in memory by strings, like if you have array x[20] and array y[2][10], then y data will be recorded in memory: first y[0] and then y[1], which will be physically located like x[20]
if there is some performance delay, it is insignificant and occurs only because of array overrun control
If the array is dynamic, it depends on the specific compiler manufacturer - how much of the memory manager code is optimized (in Delphi, most of the System module is written in ASM), because memory allocation for a multidimensional dynamic array is a bit more complicated, but then, the problem is usually not in dynamic arrays, but in the programmer - how justified and often he calls memory allocation for a dynamic array
SZS: thanks for the chat - but I can not for your lack of understanding of elementary things to spend so much time - start reading yourself
Is this also an OOP question?
if not, then: if array is static - then there will be no difference in performance when accessing both one-dimensional and two-dimensional array, because multidimensional array data is stored in memory in strings, like if you have array x[20] and array y[2][10], then y data will be recorded in memory: first y[0] and then y[1], which will be physically located like x[20]
You are wrong as you don't know the simplest things.
Data of any array is stored in memory linearly. From the first to the last, to access an element x[15], you need to calculate the address of the beginning of the array plus offset 15, which will be the address of the variable to calculate this variable. If we have a two dimensional array, for example, x[2][5], we first calculate the offset for the second row and then add to it the offset for the 5th element, i.e. twice as many operations.