Проект советника - страница 6
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В цивилизованном мире списки реализуются через...
Вот напиши цивилизованную библиотеку на MQL, а там поговорим. Эти вопли слышно годами, а как до дела дойдет - начинается откровенный быдлокодинг.
С ссылками в CObject MQ действительно накосячила. Не должно там их быть. И ссылки эти используются в очень специфических контейнерах вроде CList. Но где нет ошибок? Цивилизованные языки говоришь? Критику того же Рихтера почитай, что он думает о Object C#, и каких методов по его мнению в нем не должно быть. Так что же, из-за того что Рихтер прав, мы должны отказаться от использвания C#? Бред. Так что хватит здесь наваливать, иди наконец в свои процедурные дебри.
Ну, да, константные объекты в список не запишешь.
Но, при этом я постоянно пользуюсь функциональностью CObject, а никто из критиков ничего даже похожее на объекты массивы и списки Стандартной Библиотеки - не предложил.
"Как надо делать" - это каждый горазд орать. А вот предложить что-то - и ВНЕЗАПНО оказывается нечего.
Даже те участники, кто реально предлагают различные программные решения - не предлагают замены CObject'y - чаще вобще его не используют, реже используют его функциональность, не обращая внимания на "реализацию через одно место". А значит - реализация вполне себе годная.
Была бы плохая - давно бы уже предложили замену.
Ну обычно штатным CObject пользуются тогда, когда всё остальное тоже основано на стандартной библиотеке. В частности те, кто активно делится своими исходниками, обычно стремятся к унификации, сокращению самописного кода и уменьшения количества собственных библиотек, дабы облегчить жизнь сторонним пользователям. Но тут уж каждый сам решет, кодирует ли он для себя или для удобства других.
А так, полагаю, многие пользуются собственным решениями (как и я), просто не видят потребности предлагать их кому-то. Но в целом думаю было бы лучше, если бы был некий стандарт на основе каких-то известных библиотек, например MFC. Я поэтому не очень понимаю MQ, зачем им было изобретать собственный велосипед (к тому же весьма спорный), вместо того чтобы портировать готовое решение. Впрочем это же можно сказать и про сам язык MQL ))
Но в принципе я никого не принуждал отказываться от CObject, я лишь внёс своё критическое замечание в ответ на фразу о том, что мол зачем кто-то пользуется CMyCobject, если есть шикарнейший CObject от MQ :)
Вот напиши цивилизованную библиотеку на MQL, а там поговорим. Эти вопли слышно годами, а как до дела дойдет - начинается откровенный быдлокодинг.
Ну у меня есть свои библиотеки. Так о чём вы хотели поговорить?
С ссылками в CObject MQ действительно накосячила. Не должно там их быть. И ссылки эти используются в очень специфических контейнерах вроде CList. Но где нет ошибок? Цивилизованные языки говоришь? Критику того же Рихтера почитай, что он думает о Object C#, и каких методов по его мнению в нем не должно быть. Так что же, из-за того что Рихтер прав, мы должны отказаться от использвания C#? Бред. Так что хватит здесь наваливать, иди наконец в свои процедурные дебри.
Поменьше гонора, да и хамства тоже, я на личности с вами не переходил.
Про "накосячила со ссылками" - ну да, забавно, после того как я уже всё расписал об этом. Хотя ранее вы тут буквально дро**ли на CObject, что он такой замечательный, и что мол даже указатели там не инциализируются по умолчанию (хоть бы матчасть чтоль изучили для начала о языке, на котором кодите). В общем не вижу более смысла метать тут бисер перед вами.
Но, согласен, далеко не всегда надо использовать ООП.
Скажем, у меня есть класc CDataProvider:pulic CDataProviderI - дата провайдер, который обеспечивает эксперт таймсериями, индикаторами, данными по терминалу и окружению. Внутри эксперта может быть много ТС - каждая будет получать указатели на таймсерии и индикаторы от дата-провайдера (в результате чего не надо каждой ТС заботиться о создании этих таймсерий - дата-провайдер даст указатель на нужную таймсерию, если она уже есть, а создавать будет только те, которые еще не созданы).
Когда надо получить индикатор из дата-провайдера - надо заполнить структуру описания индикатора, и потом запросить у провайдера индикатор, указав на эту структуру.
Соответственно, каждый индикатор внутри дата-провайдера должен уметь опознавать свою структуру (дата-провайдер "знаком" только с абстрактным базовым классом структуры), и по ней - создать готовый объект индикатора - который и будет выдан дата-провайдером.
Но, городить весь этот огород ради того, чтобы проверить новую идею какого-то индикатора - конечно, неразумно. В результате - для таких новых индикаторов - все "собирается на коленке", безо всякого ООП. Однако, если я вижу, что индикатор полезен для советников - то он пишется "как положено" - с полной ООП-поддержкой, и созданием внутри дата-провайдера.
когда, лет 15 назад я тестировал все индикаторы в мт4 на пригодность к торговле в режиме реверса позиции, нашел только 1 дающий прибыль на дневке. большинство индикаторов построено на основе встроенных индикаторов, как следствие результативность торгов низкая практически у всех. изучение рынка на предмет точности прогноза или прибыльности патерна я считаю первая задача любого трейдера. окружение и описание функций, это необходимость комфорта в работе на уже найденной закономерности, дающей профит.
с уважением.
P.S. а критики, хамы, просто любители потролить, всегда будут. главное чтоб они не могли вас сбить с того направления, в котором вы идете и видите реализацию своих идей. ведь задача всего этого цирка, сбить с толку и направить в не верном направлении, подальше от прибыли.
Ну вот ты и сам ответил на вопрос, зачем стоит использовать CObject, а не самописный велосипед. Это нужно, что бы облегчить жизнь не только другим но в первую очередь себе самому, потому что слова "унификация", "сокращение самописного кода", "уменьшение количества собственных библиотек" - это то к чему нужно стремиться каждому разработчику. Это свещенный грааль программиста.
Конечно, стандартная библиотека устарела. Сейчас язык позволяет делать генерики, и вот вот будут интерфейсы. Но старая либа работает и это хорошая унификация, а лучшее как говорится враг хорошего. Т.к. нет этого самого идеального и лучшего нужно использовать хорошее.
Про "накосячила со ссылками" - ну да, забавно, после того как я уже всё расписал об этом. Хотя ранее вы тут буквально "дро**ли" на CObject, заявляя что он такой замечательный, и что мол даже указатели там не инциализируются по умолчанию (вы бы хоть матчасть чтоль изучили для начала о языке, на котором кодите). В общем не вижу более смысла метать тут бисер перед вами.
Никто перед тобой ниц падать здесь не будет. Поверь, то "сокральное" знание, что ты здесь нам всем "открыл" давно известно многим. На счет инициализации ссылок - даже спорить не буду. Ты знаешь, что формально ты прав, вот и пытаешься тыкать меня носом в одно и тоже: мол читай мат часть, учи что такое NULL и прочее, прочее. Но меня учить не надо. Ты же крутой. У тебя все есть. Так зачем здесь метаешь бисер перед нами? Иди лучше по;%:№%; на свою библиотеку. Глядишь она заработает 0.5% быстрее.
замечательное решение для множества тс применяющих в свое работе одни и те же индикаторы. но для тестов не годиться, потому и приходиться писать на коленке.
когда, лет 15 назад я тестировал все индикаторы в мт4 на пригодность к торговле в режиме реверса позиции, нашел только 1 дающий прибыль на дневке. большинство индикаторов построено на основе встроенных индикаторов, как следствие результативность торгов низкая практически у всех. изучение рынка на предмет точности прогноза или прибыльности патерна я считаю первая задача любого трейдера. окружение и описание функций, это необходимость комфорта в работе на уже найденной закономерности, дающей профит.
Не, ну тут надо просто правильно подходить к сущности индикатора. Индикатор - это тебе не готовый Грааль, а просто удобное выражение некоторых особенностей хода цены. Соответственно, подход к ним и должен быть вовсе не как "окончательному источнику сигналов", а просто как к некому "признаку сигнала" и использовать их в комплексе. А в таком случае - многие индикаторы начинают требоваться в большинстве испытаний. В частности, скажем, ATR - я уже подумываю стандартно встроить в шаблон советника, поскольку он у меня практически везде используется. Те же МАшки - тоже вполне себе часто требуемые индикаторы. Фракталы, индикаторы пинбаров...
...
Но, согласен, далеко не всегда надо использовать ООП.
Скажем, у меня есть класc CDataProvider:pulic CDataProviderI - дата провайдер, который обеспечивает эксперт таймсериями, индикаторами, данными по терминалу и окружению. Внутри эксперта может быть много ТС - каждая будет получать указатели на таймсерии и индикаторы от дата-провайдера (в результате чего не надо каждой ТС заботиться о создании этих таймсерий - дата-провайдер даст указатель на нужную таймсерию, если она уже есть, а создавать будет только те, которые еще не созданы).
Когда надо получить индикатор из дата-провайдера - надо заполнить структуру описания индикатора, и потом запросить у провайдера индикатор, указав на эту структуру.
Соответственно, каждый индикатор внутри дата-провайдера должен уметь опознавать свою структуру (дата-провайдер "знаком" только с абстрактным базовым классом структуры), и по ней - создать готовый объект индикатора - который и будет выдан дата-провайдером.
Но, городить весь этот огород ради того, чтобы проверить новую идею какого-то индикатора - конечно, неразумно. В результате - для таких новых индикаторов - все "собирается на коленке", безо всякого ООП. Однако, если я вижу, что индикатор полезен для советников - то он пишется "как положено" - с полной ООП-поддержкой, и созданием внутри дата-провайдера.
P.S.
Кстати, вот в случае с индикаторами и дата-провайдером хорошо видно преимущество в виртуализации наследовании. У нас есть базовый интерфейс параметров индикатора CIndicatorParametersI, наследник этого интерфейса - это реальные параметры необходимого индикатора. При запросе индикатора мы объявляем эти параметры, и передаем дата-провайдеру указатель на абстрактный интерфейс. Таким образом, сам дата-провайдер даже не знает, какой индикатор запрошен - это определяется в одной функции, в которой индикатор создается по new, того типа, который нужен. И про то, какие именно параметры переданы - знает только этот созданный индикатор, который и извлекает нужные параметры из переданного объекта.
Фишка в том, что практически везде внутри дата-провайдера идет работа с простым базовым классом параметров (или индикаторов) - дата-провайдеру доступны только самые простые и общие функции базовых интерфейсов. Это упрощает модификацию кода (когда она необходима), и не создает соблазн "влезать" в код индикаторов из дата-провайдера. Если нужно изменить индикатор - то это делается только внутри самого индикатора, дата-провайдер же - это только хранилище индикаторов, максимум, что он может сделать - это создать новый индикатор.
Вы по-моему усложняете. Дата-провайдер это сам MetaTrader. Т.е. правайдер на самом деле не нужен, а нужен лишь удобный интерфейс для работы с данными. Например, в моей либе, что бы получить цену октрытия последнего бара, рабочего инструмента нужно просто написать:
Объект WS всегда есть и он всегда под рукой и работает. Как он это делает спрятано за кулисами. Вот и весь доступ к данным:)
з.ы. ООП должно снижать сложность использования системы, а не увеличивать его. А если Вы сами признаетесь, что нужно городить огород ради простой проверки, значит что-то не то в Вашей архитектуре с провайдером. Т.е. Вы напрограммировали то, что сами не всегда хотите использовать.Не, ну тут надо просто правильно подходить к сущности индикатора. Индикатор - это тебе не готовый Грааль, а просто удобное выражение некоторых особенностей хода цены. Соответственно, подход к ним и должен быть вовсе не как "окончательному источнику сигналов", а просто как к некому "признаку сигнала" и использовать их в комплексе. А в таком случае - многие индикаторы начинают требоваться в большинстве испытаний. В частности, скажем, ATR - я уже подумываю стандартно встроить в шаблон советника, поскольку он у меня практически везде используется. Те же МАшки - тоже вполне себе часто требуемые индикаторы. Фракталы, индикаторы пинбаров...
речь шла о работе в режиме "постоянно в рынке" по сигналу индикатора разворот, и еще раз повторюсь 15 лет назад, сейчас мое видение рынка несколько изменилось.
с уважением.
Вы по-моему усложняете. Дата-провайдер это сам MetaTrader. Т.е. правайдер на самом деле не нужен, а нужен лишь удобный интерфейс для работы с данными. Например, в моей либе, что бы получить цену октрытия последнего бара, рабочего инструмента нужно просто написать:
Объект WS всегда есть и он всегда под рукой и работает. Как он это делает спрятано за кулисами. Вот и весь доступ к данным:)
з.ы. ООП должно снижать сложность использования системы, а не увеличивать его. А если Вы сами признаетесь, что нужно городить огород ради простой проверки, значит что-то не то в Вашей архитектуре с провайдером. Т.е. Вы напрограммировали то, что сами не всегда хотите использовать.Твоя (давай на "ты") запись "WS.Open[0];" очень мало отличается от моей записи "m_tcMainContainer.Open(0)"
Подозреваю, что в инициализации для объекта WS должны быть какие-то предварительные действия.
В моем случае надо вызывать функцию bool _LoadMainTimeseriesToLocalContainer(uint uiNeedBuffer).
В каждой части эксперта (в генераторе входов, в контроллерах трейлинга и выхода - то есть в объектах, которые могут совершать торговые действия) у меня есть объект "Контейнер таймсерий" - по сути, это указатель на таймсерии OHLCSTVtVr c дополнительными сервисными возможностями.
В эксперте могут существовать много различных контейнеров разных символов и разных таймфреймов. Идеология дата-провайдера позволяет не дублировать их. Поскольку реально - все таймсерии хранятся именно в нем, а контейнеры - просто указывают на необходимые.
Я не вижу особой разницы - как я понимаю, WS (WareStore, вероятно ?) - это все тот же мой дата-провайдер. Просто в моем дата-провайдере также сконцентрированы и остальные данные - индикаторы, символы (Объекты CSymbolInfo), терминал (объект CTerminalInfo), в котором также есть и коллекция чартов. В каждом рефреше таймсерии обновляются (по мере необходимости) - здесь идеология близка к идеологии Стандартной Библиотеки.
Если считать за провайдер данных сам МТ4-5, а наш класс использовать только для обеспечения доступа - то, выходит, по вашему обращению к цене Open - мы должны вызывать функцию CopyOpen() для одного значения - мне это кажется неразумным.
Давать полный глобальный доступ ко всем переменным в любом месте программы я также считаю крайне неразумным, наоборот, я стараюсь в каждом месте программы иметь доступ исключительно только к тем структурам и данным, которые необходимы для данного действия. Все остальное - должно быть недоступно. Идеология дата-провайдера как раз позволяет контролировать этот доступ.
АТР я не считаю за индикатор, он показывает среднюю волатильность рынка за какой то период времени, как сигнал для входа не годиться (его можно применять как фильтр, не более). машки дают отрицательную прибыль в режиме реверса позиции. фракталы так же. индикатор пинбаров не является встроенным.
речь шла о работе в режиме "постоянно в рынке" по сигналу индикатора разворот, и еще раз повторюсь 15 лет назад, сейчас мое видение рынка несколько изменилось.
с уважением.
То есть как это "ATR не считаю за индикатор" ???
И как это "не годится, как сигнал для входа ??? А я-то дурень, использую вход "пробой волатильности" с использованием исключительно этого индикатора...
Я так подозреваю, что у вас свое, особое понимание сущности индикаторов... Для меня индикатор - это объект, который может выдавать некоторое изменяемое значение, в зависимости от времени. По сути, даже обычный свечной график цены - это тоже индикатор. А для вас это что-то другое... Соответственно, и понимание у нас разное.