Questions on OOP in MQL5 - page 66

New comment
 

Here's the answer why:

In the red rectangle - added one call toGetMicrosecondCount(), in the blue one - one more. That's why it's almost equal.

 
Dmitry Fedoseev:

Why are you daring to show me the code? Without the code, you can shove your time pictures where the sun don't shine.

 
Vladimir Simakov:

Oops. With identical actions, there was only a 30% difference.

Perhaps it is in the classes that the overhead is created? Of course, the compiler should in any case inline everything and cut out unnecessary stuff. It makes sense to point this out to the developers.
 
Alexey Navoykov:
Maybe it's classes that create the overhead? Of course, the compiler should in any case inline everything and cut out unnecessary things. It makes sense to point this out to the developers.

It worked. The structure worked at the same speed as the function and macro. But the class... far behind.

 
Dmitry Fedoseev:

It worked. The structure worked at the same speed as the function and macro. But the class... far behind.

Basically, I've always had such a hunch, but I just never got around to testing it. That's why I tried to avoid declaring the class unnecessarily and declared it as a structure, especially if the idea is to pass it on the stack.
 

I gave advice on how to access private methods/fields in SB and picked up this hook on the forum myself, I don't remember who suggested it.

i was surprised to find out that i was giving advice as usual without sticking to the terminology, it was not a hook but an anti-pattern Public Morozovhttp://blog.kislenko.net/show.php?id=1775

)))

 
Igor Makanu:

I gave advice on how to access private methods/fields in SB and picked up this hook on the forum myself, I don't remember who suggested it.

i was surprised to find out that i was giving advice as usual without sticking to the terminology, it was not a hookbut an anti-pattern Public Morozovhttp://blog.kislenko.net/show.php?id=1775

)))

there you have given a barrel of honey to pattern deniers and OO lovers :-) A pattern to get what is hidden by design considerations :-)

Someone (someone from current OO/C++ monsters), quite reasonably said that the sticking point of OO is that the base class must provide sufficient interfaces for all descendant variations (practically have available setters-getters to all fields, or all-in-one),
and descendants cannot create virtual functions outside parent protocol, only then will universal happiness come. Then generalized STL+boost really saves, tests are useful and reusable. But it becomes a lot of classes, because instead of new virtual functions all sorts of proxies act.

 
Maxim Kuznetsov:

here you have given a barrel of honey to pattern deniers and OO lovers :-) Pattern to get what is hidden by design considerations :-)

Someone (someone from current OO/C++ monsters), quite reasonably said that the sticking point of OO is that the base class must provide sufficient interfaces for all descendant variations (practically have available setters-getters to all fields, or all-in-one),
and descendants must not create virtual functions outside parent protocol, only then will universal happiness come. Then generalized STL+boost really saves, tests are useful and reusable. But it becomes a lot of classes, because all sorts of proxies act instead of new virtual functions.

What do patterns and OO lovers have to do with it?

 
Maxim Kuznetsov:

Someone (someone from the current OO/C++ monsters), quite sensibly said that the sticking point of OO is that the base class must provide sufficient interfaces for all variations of descendants (practically have setter-getters available to all fields, or all-in-a-blank)

I don't know what "monster" said such nonsense. He seems to be a supporter of cramming everything that can and cannot be crammed into one class: "...the reaper and the healer".
 
Speaking of "anti-patterns", almost the entire standard MQ library, for example, is one solid anti-pattern.)
1...596061626364656667686970717273...96
New comment