Ошибка изменения размера массива в бета-версии сборки 530 - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Если вы хотите проверить, и избежать обновления другого терминала, вы должны удалить следующую папку :
Эта информация (вероятно, взятая с русского форума) уже неактуальна. Начиная с версии 534, обновление на Win7+ помещается в %appdata%\metaquotes\webinstall, а не в %programdata%\metaquotes\webinstall.
Может измениться в последующих версиях.
Эта информация (вероятно, взятая с русского форума) уже неактуальна. Начиная с версии 534, обновление на Win7+ помещается в %appdata%\metaquotes\webinstall, а не в %programdata%\metaquotes\webinstall.
Может измениться в последующих версиях.
Я, наверное, не очень хороший пример, так как я профессиональный программист. Так что для меня это не требует больших усилий, и я люблю изучать новые языки программирования. У меня тоже есть некоторый опыт работы с oop.
. . . . .
Имхо, ООП подразумевает веру в инкапсуляцию, абстракцию, наследование и полиморфизм. Я не думаю, что вы должны уметь "следовать" чужим кодам из-за абстракции. Все, что вам нужно знать, это то, что она делает
. Если говорить более серьезно, я считаю, что ООП обеспечивает уровень организации/каталогизации, который навязывается и поддерживается языком и IDE. Программист не может иметь слишком много организации, это, вероятно, в конечном итоге экономит время на будущих проектах для большинства программистов.
Спасибо за ваш ответ angelvoyager, это было хорошее понимание от того, кто знаком с обеими сторонами медали, я в той же лодке, что и Raptor, концепции oop начали интересовать меня, и я хочу узнать о них больше, хорошо знать, что это не совсем необходимо для продолжения использования mql4 даже с функциями mql5, но все же, я хотел бы понять, каковы преимущества кодирования в соответствии с концепциями и принципами oop и насколько хорошо они применимы к кодированию небольшого проекта, такого как советник.
Когда я кодирую советника, он обычно получается таким же, как в книге: центральная функция, которая накапливает текущее состояние дел и хранит эту информацию в глобальных массивах, окруженных периферийными функциями, которые используют информацию в этих же массивах, чтобы решить, что делать, каждая из которых вызывает другие вспомогательные функции для расчета таких вещей, как размер лота и т. д. Функция start() просто вызывает сначала центральную функцию-концентратор, а затем периферийные функции в порядке приоритета. Эта базовая структура работает довольно хорошо, хотя мне никогда не нравилось, что все дело сосредоточено на глобальном доступе к этим массивам, но мне это не нравилось настолько, чтобы искать другой способ сделать это. Другими словами, он работает достаточно хорошо, поэтому я не пытался его исправить lol.
Я хотел бы знать, чем подход oop отличается от этого и какие у него преимущества.
Я хотел бы узнать, чем отличается подход oop от этого и каковы его преимущества.
Я полагаю, что вы описываете поток программы. Я не думаю, что это большая идея, стоящая за ООП. (имо) ООП пытается решить следующие проблемы. Я ноб в ООП, но я формирую свое мировоззрение по этому поводу.
1) Являются ли ваши функции независимыми от глобальных переменных? Другими_словами, являются ли ваши функции самостоятельными объектами? Инкапсуляция
2) Скрывает ли ваша функция такие детали, как локальные_имена_переменных? Упрощает ли она объем кода на экране? Абстракция
3) Имеет ли она возможность создавать дубликаты самой себя для модификации? Например, возможность создавать собственные типы данных? Наследование.
4) Имеет ли она возможность изменяться на лету? Пример: может ли функция обрабатывать integer_array, а также double_arrays? Полиморфизм.
Способы, которыми ООП может помочь в построении_ea, похожи на то, как ea_builder помогает не_программисту построить эксперта. Вы просто берете свою любимую функцию Order_Accounting_Function -> Data_Function -> Event Tracking Function -> Volume Defining Function -> Trading Criteria Defining Function -> Trade Functions -> Error Processing Function. И бум, у вас есть Expert_Advisor. Все ваши функции определения торговых критериев, которые вы разрабатывали годами, могут быть легко заменены на другие.
Например, если вы захотите изменить мой советник, вам нужно будет изучить, где применяются мои глобальные переменные и какая другая функция зависит от них (как в массивах состояний или статусов). ООП делает это так_просто_как Accounting(Option_3); Display(Option_1); Caption(Option_5); TradingSys(Option_7); VolumeSize(Option2); OrderType(Option_2) и это весь эксперт.
Это облегчает другим людям использование вашего набора библиотек, и обычно то, что работает для кого-то другого, работает и для вас в будущем. Если ничего другого нет, просто представьте себе отдельные объекты на конвейере :)
Последняя версия моего эксперта уже близка к этому, теперь она состоит из всех включаемых файлов, но они недостаточно надежны, чтобы использовать их из коробки без некоторых модификаций. Ошибка, которую я часто совершаю, заключается в том, что я не замечаю, что пишу код, специфичный для критериев, в функции, которые должны быть неоднозначными, до тех пор, пока это не произойдет, и они слишком сильно полагаются на глабальные массивы, когда у меня появится время, я собираюсь использовать больше локальных массивов и больше передачи параметров, чтобы компенсировать меньший глобальный доступ.
***Пс: (Я не хочу забывать об этом). Конечно, большинству из нас не нравится не_знать, что содержится в кодах, которые мы используем. Или же мы поглощены попытками понять чужие коды, иначе мы, вероятно, не стали бы их использовать. Однако, большинство нативных функций (пример OrderSend()) в mql4 являются объектами с нашей точки зрения. Мы не видим их коды, однако мы принимаем их. Я считаю, что принятие чужих библиотек - это то, что профессиональный_oop_программист, работающий над большими проектами, должен принимать и развивать. В противном случае вы застрянете в повторном создании колеса.