Интересная тема для многих: что будет нового в MetaTrader 4 и MQL4 - большие изменения на подходе - страница 10

 

Не забывайте, что у нас работает очень хороший инлайнер, который сливает массу мелких функций, так что потерь скорости нет.

Причем в большинстве случаев вызовы виртуальных функций через vtable оптимизируются в прямые вызовы. Это один из эффективных методов оптимизатора. Что вкупе с многократным инлайнингом позволяет практически полностью избавляться от сложных многоуровневых вызовов и превращать код в плоский вид.

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

Не забывайте, что у нас работает очень хороший инлайнер, который сливает массу мелких функций, так что потерь скорости нет.

Причем в большинстве случаев вызовы виртуальных функций через vtable оптимизируются в прямые вызовы. Это один из эффективных методов оптимизатора. Что вкупе с многократным инлайнингом позволяет практически полностью избавляться от сложных многоуровневых вызовов и превращать код в плоский вид.

:) улыбнуло. А никто и не спорит что компилятор отлично оптимизирует код, я просто довожу до товарища мысль почему я не падаю ниц перед СБ.

Хорошо давайте на примерах:

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"

на практике заменяется простой стандартной функцией

CopyBuffer(...);

имеем искусство ради искусства. И так по каждому элементу который что то делает (остальные как понимаете пишутся для того чтоб конечные элементы работали).

Да соглашусь универсальность, да соглашусь хорошо структурированный код (можно сказать образец для изучения).

А суть то в чём? А суть в том что эта библа в первую очередь нужна для "Мастера MQL5" и как учебное пособие по ООП.

 
Urain:

 я просто довожу до товарища мысль почему я не падаю ниц перед СБ.

Да-да, я еще раз подчеркну - ни по одному вашему доводу у меня нет серьезных возражений. Спор по этому поводу будет скорее религиозен, чем объективен.

Вот, как раз на вашем же примере, лично МНЕ, и В МОЕМ СЛУЧАЕ кажется более приемлемым именно первый вариант кода, именно за счет всех этих многоуровневых включений, которые обеспечивают универсальность и совместимость индикатора со всеми интерфейсами, начиная от CObject'a, и заканчивая CiCustom'om.  Данный объект может быть передан любому пользователю, который умеет работать с одним из этих уровней, и никаких дополнительных усилий не понадобится.

Но, с другой стороны - это у меня все таймсерии и индикаторы создаются по запросу, укладываются в  единую коллекцию, и потом доступны всем пользователям. А когда нужно ОДИН РАЗ скопировать буффер - возникает вопрос - нафига огород городить ?

Поэтому в простом случае - безусловно, будет гораздо проще использовать CopyBuffer().

Но что делать, если у нас десяток пользователей данного буффера ? В моем случае - они все обратятся за буффером, по первому же требованию буффер будет создан, и все остальные - просто получат ссылку на него. А если мы будем использовать CopyBuffer() "в лоб" - то у нас будет десять копирований вместо одного. При более хитром же использовании CopyBuffer() мы получаем навороты с отслеживанием, кому и какой буффер был выделен, которые вполне эквивалентны по затратам упомянутой вами инкапсуляцией. 

 

Лично я - за разумность. Для одного места городить огород с ООП не имеет смысла. Если же у нас пользователей много, то ООП-подход, на мой взгляд, оправдывает себя. 

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

Тогда пора вводить исключения для того чтоб один код можно было скомпилить и под mql4 и mql5.

Вопрос унификации как бэ назревает.

Поддерживаю. Очень удобная фича.
C-4:
Вот тут подумалось что при объединении двух языков абсолютно необходимы условные директивы компиляции типа #ifdef - это бы существенно упростило бы унификацию кодов между двумя платформами, и плотформозависимый API определялся на этапе компиляции. 
Нас уже как минимум четверо :)
 
Renat:
К сожалению, нет. Тестер останется однопоточный и без MQL5 Cloud Network.
А как на счет мультивалютности?
 
В Мт4 идеология тестера останется та же самая. На коренные изменения не пойдем по крайней мере в ближайшее время.
 
Renat:

Не забывайте, что у нас работает очень хороший инлайнер, который сливает массу мелких функций, так что потерь скорости нет.

Причем в большинстве случаев вызовы виртуальных функций через vtable оптимизируются в прямые вызовы. Это один из эффективных методов оптимизатора. Что вкупе с многократным инлайнингом позволяет практически полностью избавляться от сложных многоуровневых вызовов и превращать код в плоский вид.

Аааа... Теперь понятно, почему одна из самых частых ошибок у меня при написании программы является "Function must have a body".

Это инлайнер требует... А то мне было удивительно, вроде как для компиляции модуля вполне достаточно заголовка функции, но нет... Нужно тело...

Ну и хорошо.  

 
Laryx:

Аааа... Теперь понятно, почему одна из самых частых ошибок у меня при написании программы является "Function must have a body".

Это инлайнер требует... А то мне было удивительно, вроде как для компиляции модуля вполне достаточно заголовка функции, но нет... Нужно тело...

Все верно пишет, но это не имеет отношения к оптимизатору.

Если описали прототип функции класса, то тело обязано быть. Пусть даже пустое.

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

Renat, предлагаю в МТ4 сделать управление видимостью позиций на графике не в общих параметрах терминала, а отдельно для каждого графика (как это было сделано в МТ5).

Моя заявка в СД по этому поводу уже второй месяц валяется без движения.

 
Interesting:

Renat, предлагаю в МТ4 сделать управление видимостью позиций на графике не в общих параметрах терминала, а отдельно для каждого графика (как это было сделано в МТ5).

Моя заявка в СД по этому поводу уже второй месяц валяется без движения.

Во время работы над объектами посмотрим.
Причина обращения: