Как Вы учили язык MQL4/5? - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Нет. Класс CTradeProcessor написан очень давно, фактически, сразу с появлением 600го билда.
С тех пор я просто его использую, и даже не помню, что там и как, и чем отличаются, скажем, блоки, отвечающие за МТ4 и МТ5 (пары файлов MT5TradeProcessor.mq. и MT4TradeProcessor.mq. )
Тем и хорош ООП-подход, что у нас есть интерфейс (выше выкладывал), а он при сборке возьмёт все необходимое, нам думать ничего не надо.
1. Не пользуются в основном адепты MQL 4. Им в пятёрке не удобно всё.
4 никогда не пользовался, в 5 начинал с CTrade, быстро отказался. Напрямую удобнее и быстрее.
По поводу мэджика - да, напутал, это к CPositionInfo претензия, при неттинге к использованию непригодно.Для написания ботиков лучше заходят всякие скриптовые ЯП.
QUIK с его Lua вам в руки ))
QUIK с его Lua вам в руки ))
QUIK с его Lua вам в руки ))
И сразу покупаем новый комп с AMD Ryzen Threadripper 96 ядер ))
Кто пользовался пишут, что неудобная
Вариантов установить несколько магиков много. Самый простой вписывать нужный магик в нужный момент. Если пользуетесь СБ и классом CTrade то перед каждым открытием позиции, открытием ордера, перед закрытием позиции или удаления ордера… Так же перед изменением позиции или ордера поставьте SetExpertMagicNumber(magic). И достаточно сложный для слабо понимающих ООП вариант, это несколько объектов и в каждом из них свой магик. Этот вариант не только для использования CTrade но и для своих библиотек.
Вариантов установить несколько магиков много. Самый простой вписывать нужный магик в нужный момент. Если пользуетесь СБ и классом CTrade то перед каждым открытием позиции, открытием ордера, перед закрытием позиции или удаления ордера… Так же перед изменением позиции или ордера поставьте SetExpertMagicNumber(magic). И достаточно сложный для слабо понимающих ООП вариант, это несколько объектов и в каждом из них свой магик. Этот вариант не только для использования CTrade но и для своих библиотек.
Да, уже разобрался. Но немного негодовал, почему нужно лезть в классы и смотреть там, а не использовать готовое терминальное. Типа бай 100 лотов с таким-то мэджиком и селл 100 лотов с другим. Зачем тогда терминал, я могу подключаться так через любое апи к любому брокеру на любом ЯП. Границы размыты.
Вы про какие АПИ говорите? Подключение СБ далеко не АПИ… Это всего лишь пародия на ООП. Я совсем недавно начал чуток понимать возможности ООП и скажу я вам, это увлекательно.
А лезть в классы приходится потому, что не читаем документацию. Правда я тут тоже не читал.
Вы про какие АПИ говорите? Подключение СБ далеко не АПИ… Это всего лишь пародия на ООП. Я совсем недавно начал чуток понимать возможности ООП и скажу я вам, это увлекательно.
А лезть в классы приходится потому, что не читаем документацию. Правда я тут тоже не читал.
ООП хорош в высокоуровневых ЯП, например в питоне все есть ООП :) когда это низкоуровневый ООП - пиши пропало с точки зрения обычного юзера терминала. Просто простыни бессмысленного и беспощадного кода. Это же никакая нервная система не выдержит :)
Напрасно ты так, дружище.
Тебе уже предложили стандартный класс CTrade - который предоставляет именно то, что тебе нужно, "простые функции Бай-Селл". Мой ТрейдПроцессор - делает абсолютно тоже самое (с учётом некоторых моих предпочтений).
Инкапсуляция - великая вещь. Сперва пишется интерфейс - фактически, чисто принципы, на которых будут взаимодействовать части программы. Вот, в данном случае CTrade. После этого тем, кто будет писать CTrade, и тем, кто его будет использовать - совершенно не надо ни о чём договариваться - они работают исключительно через установленный интерфейс класса, и любые изменения не мешают друг другу.
В процедурном программировании - процедуры Бай-Селл могут затрагивать общие данные, и нет гарантии, что эти данные не будут изменены одной стороной без уведомления второй, что приводит к иногда очень хитрым и сложным в устранении ошибкам.
Вот, прямо по теме ветки - для процедурного программирования надо знать, в каком терминале ты находишься. И если в МТ4 - то использовать одни функции, а если в МТ5 - оооо... начинается вселенский вой.
В ООП-программировании - мы берём класс CTrade - и вобще не думаем, на каком терминале мы работаем. Используем функции, предоставляемые этим классом, а в каком терминале, и какие функции самого терминала использовать - это пусть голова болит у тех, кто пишет этот самый CTrade.
Или, вот, тут верно заметили - в торговой истории - сам чёрт ногу сломит.
Хорошо, у меня уже давно написан класс CTradeHistoryI, который предоставляет интерфейс для работы с историей, и опять же - не надо думать, где мы, в каком терминале, и какие функции использовать - просто пользуемся этим интерфейсом.
ООП - как раз предоставляет огромное удобство, и как раз уменьшает количество необходимого кода! А то, что файл за собой тянет сотню других (и реально кода, и в самом деле, может быть на порядок больше) - так то пусть голова болит у терминала, у компьютера, у автора класса... Нам об этом думать не требуется. Мы используем именно предоставленный интерфейс.
Кстати, функции МТ4 (и МТ5) - это ведь и есть предоставленный интерфейс, что там реально внутри - никто на этом форуме и не знает... Все их просто используют, как "черные ящики". Именно благодаря ООП-подходу.