Интересная тема для многих: что будет нового в MetaTrader 4 и MQL4 - большие изменения на подходе - страница 10
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Не забывайте, что у нас работает очень хороший инлайнер, который сливает массу мелких функций, так что потерь скорости нет.
Причем в большинстве случаев вызовы виртуальных функций через vtable оптимизируются в прямые вызовы. Это один из эффективных методов оптимизатора. Что вкупе с многократным инлайнингом позволяет практически полностью избавляться от сложных многоуровневых вызовов и превращать код в плоский вид.
Не забывайте, что у нас работает очень хороший инлайнер, который сливает массу мелких функций, так что потерь скорости нет.
Причем в большинстве случаев вызовы виртуальных функций через vtable оптимизируются в прямые вызовы. Это один из эффективных методов оптимизатора. Что вкупе с многократным инлайнингом позволяет практически полностью избавляться от сложных многоуровневых вызовов и превращать код в плоский вид.
:) улыбнуло. А никто и не спорит что компилятор отлично оптимизирует код, я просто довожу до товарища мысль почему я не падаю ниц перед СБ.
Хорошо давайте на примерах:
на практике заменяется простой стандартной функцией
CopyBuffer(...);
имеем искусство ради искусства. И так по каждому элементу который что то делает (остальные как понимаете пишутся для того чтоб конечные элементы работали).
Да соглашусь универсальность, да соглашусь хорошо структурированный код (можно сказать образец для изучения).
А суть то в чём? А суть в том что эта библа в первую очередь нужна для "Мастера MQL5" и как учебное пособие по ООП.
я просто довожу до товарища мысль почему я не падаю ниц перед СБ.
Да-да, я еще раз подчеркну - ни по одному вашему доводу у меня нет серьезных возражений. Спор по этому поводу будет скорее религиозен, чем объективен.
Вот, как раз на вашем же примере, лично МНЕ, и В МОЕМ СЛУЧАЕ кажется более приемлемым именно первый вариант кода, именно за счет всех этих многоуровневых включений, которые обеспечивают универсальность и совместимость индикатора со всеми интерфейсами, начиная от CObject'a, и заканчивая CiCustom'om. Данный объект может быть передан любому пользователю, который умеет работать с одним из этих уровней, и никаких дополнительных усилий не понадобится.
Но, с другой стороны - это у меня все таймсерии и индикаторы создаются по запросу, укладываются в единую коллекцию, и потом доступны всем пользователям. А когда нужно ОДИН РАЗ скопировать буффер - возникает вопрос - нафига огород городить ?
Поэтому в простом случае - безусловно, будет гораздо проще использовать CopyBuffer().
Но что делать, если у нас десяток пользователей данного буффера ? В моем случае - они все обратятся за буффером, по первому же требованию буффер будет создан, и все остальные - просто получат ссылку на него. А если мы будем использовать CopyBuffer() "в лоб" - то у нас будет десять копирований вместо одного. При более хитром же использовании CopyBuffer() мы получаем навороты с отслеживанием, кому и какой буффер был выделен, которые вполне эквивалентны по затратам упомянутой вами инкапсуляцией.
Лично я - за разумность. Для одного места городить огород с ООП не имеет смысла. Если же у нас пользователей много, то ООП-подход, на мой взгляд, оправдывает себя.
Тогда пора вводить исключения для того чтоб один код можно было скомпилить и под mql4 и mql5.
Вопрос унификации как бэ назревает.
Вот тут подумалось что при объединении двух языков абсолютно необходимы условные директивы компиляции типа #ifdef - это бы существенно упростило бы унификацию кодов между двумя платформами, и плотформозависимый API определялся на этапе компиляции.
К сожалению, нет. Тестер останется однопоточный и без MQL5 Cloud Network.
Не забывайте, что у нас работает очень хороший инлайнер, который сливает массу мелких функций, так что потерь скорости нет.
Причем в большинстве случаев вызовы виртуальных функций через vtable оптимизируются в прямые вызовы. Это один из эффективных методов оптимизатора. Что вкупе с многократным инлайнингом позволяет практически полностью избавляться от сложных многоуровневых вызовов и превращать код в плоский вид.
Аааа... Теперь понятно, почему одна из самых частых ошибок у меня при написании программы является "Function must have a body".
Это инлайнер требует... А то мне было удивительно, вроде как для компиляции модуля вполне достаточно заголовка функции, но нет... Нужно тело...
Ну и хорошо.
Аааа... Теперь понятно, почему одна из самых частых ошибок у меня при написании программы является "Function must have a body".
Это инлайнер требует... А то мне было удивительно, вроде как для компиляции модуля вполне достаточно заголовка функции, но нет... Нужно тело...
Все верно пишет, но это не имеет отношения к оптимизатору.
Если описали прототип функции класса, то тело обязано быть. Пусть даже пустое.
Renat, предлагаю в МТ4 сделать управление видимостью позиций на графике не в общих параметрах терминала, а отдельно для каждого графика (как это было сделано в МТ5).
Моя заявка в СД по этому поводу уже второй месяц валяется без движения.
Renat, предлагаю в МТ4 сделать управление видимостью позиций на графике не в общих параметрах терминала, а отдельно для каждого графика (как это было сделано в МТ5).
Моя заявка в СД по этому поводу уже второй месяц валяется без движения.