Yep. It's ungodly to cast directly like that. In pluses there is dynamic_cast specifically for this purpose, here you can't cast completely correctly and it is a potential source of implicit and serious errors. And in terms of seriousness it is not much better than unsafe pointers and references.
The thing is that the inheritor classes CChartObjectRectLabel, CChartObjectButton and CChartObjectEdit, have their own unique methods that need to be accessed. And the base class CChartObject from the standard library does not have the same virtual ones.
//--- objects[0]. // How to get access to methods of CChartObjectEdit class ?// 1.Print("((CChartObjectEdit *)objects[0]).BackColor(): ",((CChartObjectEdit *)objects[0]).BackColor());
//--- 2.
CChartObjectEdit *e=(CChartObjectEdit *)objects[0];
Print("e.BackColor(): ",e.BackColor());
//--- objects[1]. // How to access methods of CChartObjectButton class ?// 1.Print("((CChartObjectButton *)objects[1]).State(): ",((CChartObjectButton *)objects[1]).State());
//--- 2.
CChartObjectButton *b=(CChartObjectButton *)objects[1];
Print("b.State(): ",b.State());
//--- objects[2]. // How to get access to methods of CChartObjectRectLabel class ?// 1.Print("((CChartObjectRectLabel *)objects[2]).BackColor(): ",((CChartObjectRectLabel *)objects[2]).BackColor());
//--- 2.
CChartObjectRectLabel *r=(CChartObjectRectLabel *)objects[2];
Print("r.BackColor(): ",r.BackColor());
TheXpert: Yeah. It is unorthodox to cast directly like that. In pluses there is dynamic_cast specifically for this purpose, here you cannot cast it completely correctly and it is a potential source of implicit and serious errors. And by seriousness it is not much better than unsafe pointers and references.
Yes, before asking a question here on the forum, I found on the net that C++ has the dynamic_cast operator (a mechanism of dynamic data identification).
Now I'm looking at the link above:
// The mechanism of dynamic data type identification is available only for polymorphic ones // classes (i.e. classes containing at least one virtual member function)
So it is a mandatory condition? And if there are no virtual methods in the base class, then dynamic_cast will not work?
P.S. >>> Here I am reading more about dynamic_cast (MSDN).
Allow the use of cookies to log in to the MQL5.com website.
Please enable the necessary setting in your browser, otherwise you will not be able to log in.
You are signed in. Two-factor authentication has been disabled. Set it up again and scan a new QR code, or continue with two-factor authentication disabled.
Did you find a security hole? )
Wouldn't it be better to use polymorphism?
Approximately:
The thing is that the inheritor classes CChartObjectRectLabel, CChartObjectButton and CChartObjectEdit, have their own unique methods that need to be accessed. And the base class CChartObject from the standard library does not have the same virtual ones.
On my example above...
access to methods of inheritor classes?
...it turns out like this:
Yeah. It is unorthodox to cast directly like that. In pluses there is dynamic_cast specifically for this purpose, here you cannot cast it completely correctly and it is a potential source of implicit and serious errors. And by seriousness it is not much better than unsafe pointers and references.
Yes, before asking a question here on the forum, I found on the net that C++ has the dynamic_cast operator (a mechanism of dynamic data identification).
Now I'm looking at the link above:
So it is a mandatory condition? And if there are no virtual methods in the base class, then dynamic_cast will not work?
P.S. >>> Here I am reading more about dynamic_cast (MSDN).
Shit, and you talk about language safety after that?
You probably think that you can freely cast to anything like in C/C++.
It is not so and there is nothing wrong with security.
You probably think that you can freely cast to anything as in C/C++.
It is not so and there is nothing wrong with safety.
I got this error by accident, which seems to confirm your words. )
It is not and there is nothing wrong with safety.
No, you can't properly check dynamic_cast at compile time.
The comment above shows the result of the casting check in rantime.
It is very rigid, it works on RTTI mechanism, because we know exactly who is who in case of ghosts.
The comment above shows the result of the casting check in rantime.