Interesting topic for many: what's new in MetaTrader 4 and MQL4 - big changes on the way - page 10

 

Don't forget that we have a very good inliner running, which drains a lot of small functions, so there is no loss of speed.

And in most cases, calls to virtual functions via vtable are optimised into direct calls. This is one of the effective methods of the optimizer. Which, coupled with multiple inlining, allows you to almost completely get rid of complex multi-level calls and make the code look flat.

Документация по MQL5: Основы языка / Объектно-ориентированное программирование / Виртуальные функции
Документация по MQL5: Основы языка / Объектно-ориентированное программирование / Виртуальные функции
  • www.mql5.com
Основы языка / Объектно-ориентированное программирование / Виртуальные функции - Документация по MQL5
 
Renat:

Don't forget that we have a very good inliner running, which drains a lot of small functions, so there is no loss of speed.

And in most cases, calls to virtual functions via vtable are optimised into direct calls. This is one of the effective methods of the optimizer. That, coupled with multiple inlining, allows to almost completely get rid of complex multi-level calls and make code look flat.

:) funny. And nobody argues that the compiler perfectly optimizes code, I'm just showing my friend why I don't get down before SB.

Ok let's use examples:

class CiCustom : public CIndicator : public CDoubleBuffer

                пользуется включением class CSeries : public CArrayObj который в свою очередь

                                                     пользуется включением class CArrayDouble : public CArray и

                                                                           class CArrayObj : public CArray ну и конечно куда как без

                                                                                  включения class CArray : public CObject который включает

                                                                                                           class CObject и #include "StdLibErr.mqh"

is replaced in practice by a simple standard function

CopyBuffer(...);

We have art for art's sake. And so on each element that does something (the rest, as you understand, are written for the final elements to work).

Yes, I agree the versatility, yes, I agree the well-structured code (you may say, it's a sample for analysis).

But what is the gist of it? The point is that this library is primarily needed for the MQL5 Wizard and as a tutorial on OOP.

 
Urain:

I am simply making the comrade understand why I do not fall down in front of the SB.

Yes, yes, I will emphasise again - I have no serious objection to any of your arguments. An argument on this would be more religious than objective.

Well, just on your example, personally I, and in MY CASE, find more acceptable the first variant of the code, because of all those multi-level inclusions that provide compatibility of the indicator with all interfaces, starting from CObject and up to CiCustom.

But, on the other hand - all timeseries and indicators are created on demand, stacked in a single collection, and then available to all users. And when we only need to copy a buffer once, we wonder why bother with all this trouble.

So in a simple case, of course, it would be much easier to use CopyBuffer().

But what if we have a dozen of users of given buffer? In my case - they all will ask for it, the buffer will be created and all the rest will get a reference to it. And if we use CopyBuffer() "directly" - I'll have ten copies instead of one. And when you use CopyBuffer() more cunningly, you get stuff with tracking who and what buffer was allocated, which is quite cost-equivalent to the encapsulation you've mentioned.

Personally I'm for reasonability - it doesn't make sense to make a big deal about OOP for a single place. If we have a lot of users, the OOP approach, in my opinion, justifies itself.

Документация по MQL5: Доступ к таймсериям и индикаторам / CopyBuffer
Документация по MQL5: Доступ к таймсериям и индикаторам / CopyBuffer
  • www.mql5.com
Доступ к таймсериям и индикаторам / CopyBuffer - Документация по MQL5
 
Urain:

Then it is time to introduce exceptions so that one code could be compiled for both mql4 and mql5.

The question of unification is looming.

Agreed. Very handy feature.
C-4:
I was thinking that when merging two languages, conditional compilation directives like #ifdef are absolutely necessary - this would simplify the unification of codes between the two platforms, and platform-dependent API would be defined at compile time.
There are at least four of us now :)
 
Renat:
Unfortunately, no. The tester will remain single threaded and without MQL5 Cloud Network.
What about multicurrency?
 
In Mt4 the ideology of the tester will remain the same. We will not make any fundamental changes, at least not in the near future.
 
Renat:

Don't forget that we have a very good inliner running, which drains a lot of small functions, so there is no loss of speed.

And in most cases, calls to virtual functions via vtable are optimised into direct calls. This is one of the effective methods of the optimizer. Which, coupled with multiple inlining, allows you to almost completely get rid of complex multi-level calls and make the code look flat.

Ahhhh... Now I see why one of my most frequent errors when writing a program is "Function must have a body".

It's the inliner that requires... I was wondering why I thought that a function header is enough to compile a module, but no... You need a body...

That's good.

 
Laryx:

Ahhhh... Now I see why one of my most frequent errors when writing a programme is "Function must have a body".

It's the inliner that requires... I was wondering why I thought that a function header is enough to compile a module, but no... You need a body...

It is correct, but it has nothing to do with the optimizer.

If you have described the prototype of a class function, the body must be there. Even if it is empty.

Документация по MQL5: Основы языка / Функции
Документация по MQL5: Основы языка / Функции
  • www.mql5.com
Основы языка / Функции - Документация по MQL5
 

Renat, I suggest that in MT4 we should make the visibility of positions on the chart control not in the general parameters of the terminal, but separately for each chart (as it was done in MT5).

My application to the SR on this subject has been lying dormant for two months now.

 
Interesting:

Renat, I suggest that in MT4 we should make the visibility of positions on the chart control not in the general parameters of the terminal, but separately for each chart (as it was done in MT5).

My application to the SR on this subject has been lying dormant for two months now.

While working on the objects we will see.