Questions on OOP in MQL5 - page 80

[Igor Makanu]

Vladimir Simakov:

I agree))) That's me on the plus side.))

I've seen how it all unfolds while I've been writing.

I.e. not on the plus side, but on the muzzle of the previous version will work right?

JSONObject * CActor::getJSONObject(const string json)const
{
   JSONParser parser;
   JSONValue  *jv = parser.parse(json);
   if (jv != NULL && jv.isObject() && (EACTOR_TYPE)(((JSONObject *)jv).getInt("ActorType")) == ActorType) return(jv);
   Print(__FUNCTION__ + "parser error, json = ",json);
   delete jv;
   return(NULL);
}

[Vladimir Simakov]

Igor Makanu:

while I was writing this, it's all turned around.

I.e. not on the plus side, but on the muzzle side the previous option will work right?

This option - yes))

Only it has two implicit dynamic_casts

[Sergey Dzyublik]

Vladimir Simakov:

1) Highlighted. Check only on the next line))) In the example from the creator of the lib, just the opposite, first check, then cast)
2) if JSONObject has an heir, why should it drop?

1) In fact one and the same code is being discussed for several days within this thread:here, here and here.
The fact that you found a problem in one of the examples of user usage of the library - well done, thank you.
However, you stated a problem in the logic of using the library as a whole, but in fact it turns out that the problem concerns a specific example.

2) Where did you see the statement that something should go down?
No, it could be much worse - the code will work fine, but produce incorrect results.

[Vladimir Simakov]

Sergey Dzyublik:

2) Where did you see the statement that something should go down?
No, it could be much worse - the code will work fine, but produce incorrect results.

IMHO of course, but if I in lib, when referring to an object by a pointer to a base class, get undefined behaviour, it should be reflected in the library manual (is it there?), but it shouldn't be)

[Igor Makanu]

Sergey Dzyublik:

No, it could be much worse - the code will work fine, but produce incorrect results.

unlikely, my example is a method from a base class, JSONObject * is the result of execution, it is a pointer to the parser, and the json parsing itself in the descendant method happens with the received pointer, which was to be "nailed" in my previously mentioned questions

there are quite a lot of checks, in the proposed example there are 3 pcs and in the derived class every call of getInt(), getDouble() methods occurs with checks

[Sergey Dzyublik]

Vladimir Simakov:

IMHO of course, but if I in lib, when referring to an object by a pointer to a base class, get undefined behavior, it should be reflected in the library's manual (is it there?), but it shouldn't be like that)

Again, what do pointers and non-pointers, manuals, etc. have to do with it? ?
In your example, part of the LOGIC will be removed from the function, namely the checkjv.isObject()
This LOGIC has been replaced by a check via dynamic_cast.
For the current version of the library everything is ok, but, theoretically, if in the next version there will be a new class which usesJSONObject as a base, not the fact that your example can work with it correctly.

[Vladimir Simakov]

Sergey Dzyublik:

Again, what do pointers and non-pointers, manuals, etc. have to do with it? ?
In your example, part of the LOGIC will be removed from the function, namely checkingjv.isObject()
This LOGIC has been replaced by checking via dynamic_cast.
For the current version of the library everything is ok, but, theoretically, if in the next version there will be a new class which usesJSONObject as a base, not the fact that your example will work with it correctly.

So, another version won't be able to work with it correctly either)

[Aleksey Mavrin]

Andrei Trukhanovich:
There is no UB, mql cast includes also dynamic_cast. just everything will fall in case of wrong pointer.

Is it? In case of dynamic_cast nothing will drop if you check the result for NULL. With normal cast, it will drop immediately. Or did I get it wrong?

[Maxim Kuznetsov]

Vladimir Simakov:

IMHO of course, but if in lib, when referring to an object by pointer to a base class, I get undefined behavior, it should be reflected in the library manual (is it there?), but it shouldn't be like that)

There should be an exception in the pros. And a letter to the authors, because an exception is not a good thing, just a plug. There is no such thing in mql, so classes are made up with the future in mind, with full protocol.

About the discussed json - you have only 2 options, either follow the style and solutions of the author or make your own fork. The rest is evil. 😉

[Alexey Navoykov]

Vladimir Simakov:

And it's well worth it))) NEVER cast directly from base to descendant - this is UB ( UNDEFINED BEHAVIOR).

In pluses, it is dangerous to cast references (whether upward or downward) through the standard gimme operator, which is familiar and convenient for us.