Array resize bug in beta build 530 - page 6

New comment
 
ubzen:
***Ps: (I don't wanna forget this). Sure most of us don't like not_knowing whats in the codes we're using. Or we get consumed with trying to understand the codes from someone else otherwise we probably wouldn't use it. However, most of the Native functions ( example OrderSend() ) in mql4 are Objects from our view_point. We do_not see their codes however we accept it. I believe this acceptance of other_peoples libraries is something a professional_oop_programmer working on large projects have to accept and built upon. Otherwise you're stuck re-creating the wheel.
Yes when you put it that way, we all reinvent the wheel all the time in mql4.
 
ubzen:

I believe you're describing a program flow. I don't think thats the big_idea behind OOP. (imo) OOP tries to address the following problems. I'm a OOP noob, but I'm forming my world_view on it.

1) Are your functions independent of global_variables? In other_words are your functions stand alone objects? Encapsulation

2) Does your function hide the details like local_variable_names? Does it simplify the volume of codes on the screen? Abstraction

3) Does it have the ability to create duplicate copies of itself for modifications? Like ability to create your own data types? Inheritance.

4) Does it have the ability to change on the fly? Example:Can the function handle integer_array as well as double_arrays? Polymorphism.

Ways OOP can help in building_ea is similar to how an ea_builder helps a non_programmer built an expert_advisor. You just grab your favorite Order_Accounting_Function -> Data_Function -> Event Tracking Function -> Volume Defining Function -> Trading Criteria Defining Function -> Trade Functions -> Error Processing Function. And boom, you have an Expert_Advisor. All your Trading Criteria Defining Function you've developed over the years can be easily swapped_in or out.

Me as an example, if you wanted to modify my expert advisor, you'll need to study where my global variables are being applied and what other function depends upon it (as in your state or status arrays). OOP makes it as_simple_as Accounting(Option_3); Display(Option_1); Caption(Option_5); TradingSys(Option_7); VolumeSize(Option2); OrderType(Option_2) and thats the entire expert.

This makes it easier for someone else to use your set of libraries, and usually what works for someone else works for you as-well some time in the future. If nothing else, just think stand_alone objects on an assembly line :)

Thanks for describing this so concisely ubzen, I have looked this up before and they usually go into such a long winded novel about it all, I never really got the point.
 
SDC: Thanks for describing this so concisely ubzen, I have looked this up before and they usually go into such a long winded novel about it all, I never really got the point.
You're welcome.
 
RaptorUK: There is a difference . . . I don't have any option but to use OrderSend() if I want to place an Order . . . I do have the choice to use someone elses library or not . . . even when the source is respected I still try to understand it before trying to use it, this is how some errors are found and fixed: https://www.mql5.com/en/forum/133792/page3 "And my correction for RaptorUK's comment:"
No arguments here. OOP doesn't solve the issue of bugs in codes nor does it force you to use someone else's library.
 
RaptorUK:
I have dabbled a little with mql5 and have not needed to use any OOP in the code I have written

Classes and OOP are very much an optional add-on in MQL5. The platform framework doesn't use them itself. For example, you might expect the platform to have something like an Orders collection which contained a list of Order objects, letting you write code something like the following:

for (int i = 0; i < Orders.length; i++) {
  Order O = Orders.getByIndex(i);
  if (O.symbol == "EURUSD" && O.magicNumber = 12345) {
  }
}

But that isn't the case. Instead, the way you do this is basically identical between MQL4 and MQL5:

for (int i = 0; i < OrdersTotal(); i++) {
  if (OrderGetTicket(i)) {
    if (OrderGetString(ORDER_SYMBOL) == "EURUSD" && OrderGetInteger(ORDER_MAGIC) == 12345) {
    }
  }
}

(You might also expect any EA which you write to be a class which is derived from an ExpertAdvisor class which has things like virtual OnTick and OnInit functions in its declaration. But that's not the case either. The MQL5 framework remains fundamentally non-OOP, but with the option for you to use OOP yourself for any tasks where it's useful.)

As a result, you can continue to use MQL4 code on MQL5 via a series of helper functions such as string OrderSymbol() {return OrderGetString(ORDER_SYMBOL);}. The only area where this breaks down is timeseries access, because that's organised very differently in MQL5. A function such as iOpenMQL4() in https://www.mql5.com/en/articles/81 does work, but it's hideously slow and inefficient for repeated usage.

 

(If anyone still cares, the bug report which kicked off this thread still applies in build 535. So does https://forum.mql4.com/56885/page20#861740, though it looks like MetaQuotes have had a failed attempt at fixing that one.)

 
Sorry for late reply, but sometimes I have to sleep and work

I agree with RaptorUK, documentation on mql5.com about OOP is at least imperfect. But unfortunately I don't know a good reference about oop. Al I have read is either too abstract or too basic, taking pear and apple as example of objects and fruit as class.

OOP programming is only useful if you have big project. A big project isn't necessarily 1 EA, your project can be to build a series of EA with indicator, etc...Then it's good to reuse code, and oop is mainly about code reuse, it helps you to build a structure that can easily be reuse in other program. Unfortunately I don't have time now to go in depth with that. But it's in my plan to write some articles about that.

One example of a big project is the MQL5 Wizard created by Metaquotes. It allows you to create an EA in 5 minutes with some user input. It's based on the mql5 Standard Libray which provides all the needed elements to build an EA. The same wizard can probably be done in a procedural way, but it would a lot more difficult in my opinion. And then you have to maintain this code. But these Standard libray is difficult to understand as it's not well documented and described. I created a topic to centralize all what is existing on the topic (mql5 wizard not oop).

 
ubzen:

I believe you're describing a program flow. I don't think thats the big_idea behind OOP. (imo) OOP tries to address the following problems. I'm a OOP noob, but I'm forming my world_view on it.

1) Are your functions independent of global_variables? In other_words are your functions stand alone objects? Encapsulation

2) Does your function hide the details like local_variable_names? Does it simplify the volume of codes on the screen? Abstraction

3) Does it have the ability to create duplicate copies of itself for modifications? Like ability to create your own data types? Inheritance.

4) Does it have the ability to change on the fly? Example:Can the function handle integer_array as well as double_arrays? Polymorphism.

Ways OOP can help in building_ea is similar to how an ea_builder helps a non_programmer built an expert_advisor. You just grab your favorite Order_Accounting_Function -> Data_Function -> Event Tracking Function -> Volume Defining Function -> Trading Criteria Defining Function -> Trade Functions -> Error Processing Function. And boom, you have an Expert_Advisor. All your Trading Criteria Defining Function you've developed over the years can be easily swapped_in or out.

Me as an example, if you wanted to modify my expert advisor, you'll need to study where my global variables are being applied and what other function depends upon it (as in your state or status arrays). OOP makes it as_simple_as Accounting(Option_3); Display(Option_1); Caption(Option_5); TradingSys(Option_7); VolumeSize(Option2); OrderType(Option_2) and thats the entire expert.

This makes it easier for someone else to use your set of libraries, and usually what works for someone else works for you as-well some time in the future. If nothing else, just think stand_alone objects on an assembly line :)

It's a good overview, except for polymorphism. When you said "Can the function handle integer_array as well as double_arrays" it's not about polymorphism, it's function overloading. You can also have operator overloading in mql5 (wrongly translated to operation overloading). OOP and polymorphism is more than that. I don't have time to elaborate (especially in English), so I suggest you to read mql5 introduction to polymorphism.
 
cyclops993:

Classes and OOP are very much an optional add-on in MQL5. The platform framework doesn't use them itself. For example, you might expect the platform to have something like an Orders collection which contained a list of Order objects, letting you write code something like the following:

But that isn't the case. Instead, the way you do this is basically identical between MQL4 and MQL5:

(You might also expect any EA which you write to be a class which is derived from an ExpertAdvisor class which has things like virtual OnTick and OnInit functions in its declaration. But that's not the case either. The MQL5 framework remains fundamentally non-OOP, but with the option for you to use OOP yourself for any tasks where it's useful.)

As a result, you can continue to use MQL4 code on MQL5 via a series of helper functions such as string OrderSymbol() {return OrderGetString(ORDER_SYMBOL);}. The only area where this breaks down is timeseries access, because that's organised very differently in MQL5. A function such as iOpenMQL4() in https://www.mql5.com/en/articles/81 does work, but it's hideously slow and inefficient for repeated usage.

Agree. I would add that mql5 provides more "low" level functions than mql4. For example a lot of people complain about iBarShift() not existing in mql5. But mql5 provides more detailed functions, so you can build your own iBarShift() and provides also oop so you can reuse it easily in any project (of course oop isn't mandatory to reuse it). Not sure if my explanation is clear, as my English is yet somewhat rudimentary.
 
Ovo:

OOP is quite common currently and it will attract more real coders to the MQL. But the notepad-like editor will repel most of them, I am sure.

Have you tried the mql5 metaeditor (or new mql4 editor which is the same) ? There is a lot of improvements.
12345678
New comment
Reason: