how to create objects dynamicly? (Some OOP stuff) - page 3

New comment
 

BTW, are you aware that build 1325 introduced pointers to functions?
Is that make any difference in applying triangular communication?

MQL5: Added support for pointers to functions to simplify the arrangement of event models.

To declare a pointer to a function, specify the "pointer to a function" type, for example:

typedef int (*TFunc)(int,int);

Now, TFunc is a type, and it is possible to declare the variable pointer to the function:

TFunc func_ptr;

The func_ptr variable may store the function address to declare it later:

int sub(int x,int y) { return(x-y); }
int add(int x,int y) { return(x+y); }
int neg(int x)       { return(~x);  }

func_ptr=sub;
Print(func_ptr(10,5));

func_ptr=add;
Print(func_ptr(10,5));

func_ptr=neg;           // error: neg is not of  int (int,int) type
Print(func_ptr(10));    // error: there should be two parameters

Pointers to functions can be stored and passed as parameters. You cannot get a pointer to a non-static class method. 

 
I am not sure if the usage of function pointers is implemented with MT4 too. If so, of course, its also possible to do it like that, as long as such pointers can be managed by arrays too, because this is possible with class pointers. 
 

probably is just for MT5, and from what I've seen it's still not for methods, just functions.

Anyhow I still don't get how do you define the third party ability within the base class, for instance in the context of trend line and container, where is the 3rd object.

But I'll try to read again.

 
What I seem to lack in understanding of the events model in conjuction with OO and MQL5, is what is the right kind of dispatching the events.
I mean, how and where to decide who (what class) will get what (event).
It's clear that the top dispatcher, the language native one, i.e. the language ::OnChartEvent is written just once in a project, at the top level class.

Then from here, what is the correct way or ways of dispatching events to different objects?
Should there be a dispatching event class? Should it be done just in the ::OnChartEvent based on if statements?
 
ok, I think I got it. There is a real problem of concept shifting when you come from procedural to oop.
If I got you right, then what you mean is a way for the CTrendLine to inform its price cross to a CTrade inheritant object by means of event, without having to know about CTrade existence, is that right?
 
Amir Yacoby:
What I seem to lack in understanding of the events model in conjuction with OO and MQL5, is what is the right kind of dispatching the events.
I mean, how and where to decide who (what class) will get what (event).
It's clear that the top dispatcher, the language native one, i.e. the language ::OnChartEvent is written just once in a project, at the top level class.

Then from here, what is the correct way or ways of dispatching events to different objects?
Should there be a dispatching event class? Should it be done just in the ::OnChartEvent based on if statements?
This is no question at all. OOP is based on the prinicipes of the nature. The earth doesnt feed you, it just provides the ressources and its up to you if, when and where you need what. 
 
Amir Yacoby:
ok, I think I got it. There is a real problem of concept shifting when you come from procedural to oop.
If I got you right, then what you mean is a way for the CTrendLine to inform its price cross to a CTrade inheritant object by means of event, without having to know about CTrade existence, is that right?
I claim yes. 
 
so actually each CObject now has a place of one object which is the reciever of events, and also has a registration method for the listening object to subscribe as such and an event sender method and an event handler method used by the reciever.

This is nice, it reminds me the observer pattern, only with observer has more than one possible reciever, the m_reciever is an array of objects.

Actually, I once wanted to implement the observer and because of lack of interfaces in MQL or multiple inheritence I did not. Did not think about your good idea that the same object can force the interface on both sides.


 
Amir Yacoby:
so actually each CObject now has a place of one object which is the reciever of events, and also has a registration method for the listening object to subscribe as such and an event sender method and an event handler method used by the reciever.

This is nice, it reminds me the observer pattern, only with observer has more than one possible reciever, the m_reciever is an array of objects.

Actually, I once wanted to implement the observer and because of lack of interfaces in MQL or multiple inheritence I did not. Did not think about your good idea that the same object can force the interface on both sides.


Just to encourage you, I have been using listeners a lot with MQL4.
 
Ovo Cz:
Just to encourage you, I have been using listeners a lot with MQL4.

Thanks, but I'm not feeling encouraged (:

I managed to do it, but not with a contract between the publisher and listener, I mean, the publisher had to assume that the listener has the handling method, but nothing forced that it has.
Or, I would have to inherit all listeners from a main listener object - but then of course I would lose all point because they can't inherit other classes.

Anyhow, I'm a pro at programming but definetly not in OO where I lack experience as of yet, and I am not competing with any of you experienced oo programmers like Doerk.
What I come to know is that being procedural gives you good logic and programming skills but the shift is mentally hard, specially if a procedural oriented like me faces the mission of building OO framework, it is a totally different state of mind. And the GUI part framework is the most detailed framework with many events to take care of, I think you guys will agree that among frameworks it is the hardest to build.

12345
New comment