Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Да, у меня тоже похожая ситуация. Учиться не трудно, труднее переучиваться, ломать старые привычки. Не могу до сих от многих вредных привычек процедурного программирования отучиться.
переучиваться с процедурного стиля? хм, хорошо написанный код в процедурном стиле обернуть в класс, если будет необходимость масштабировать проект, обычно не возникает проблем
На константы и статики можно просто пока забить. На интерфейсы тоже.
А вот когда все будет готово, тогда посмотреть и что-то отметить как статик, а что-то как констант. А на интерфейсы можно вообще забить.
делать много и быстро я умею,
это я решил посвятить изучению теории, вернее подтянуть MQL до того, что за последние годы появилось, даже тут многие не в курсе возможностей терминалов
а если изучать материал, то нужно его изучать правильно, имхо, ну и понять к чему ближе сейчас MQL к С++ или все таки C# , пока вроде к С++, в C# вообще народ не заморачивается с модификаторами, вернее, что студия пометит как сомнительно, максимум то и правят )))
На константы и статики можно просто пока забить. На интерфейсы тоже.
А вот когда все будет готово, тогда посмотреть и что-то отметить как статик, а что-то как констант. А на интерфейсы можно вообще забить.
Главное, чтобы константы и статики удержались. Насчет интерфейсов согласен.
переучиваться с процедурного стиля? хм, хорошо написанный код в процедурном стиле обернуть в класс, если будет необходимость масштабировать проект, обычно не возникает проблем
делать много и быстро я умею,
это я решил посвятить изучению теории, вернее подтянуть MQL до того, что за последние годы появилось, даже тут многие не в курсе возможностей терминалов
а если изучать материал, то нужно его изучать правильно, имхо, ну и понять к чему ближе сейчас MQL к С++ или все таки C# , пока вроде к С++, в C# вообще народ не заморачивается с модификаторами, вернее, что студия пометит как сомнительно, максимум то и правят )))
const - если надо запретить выполнять переменной присвоение (кроме одного раза при инициализации). Если переменная объявлена как conts, тогда при передаче ее в функцию по ссылке, аргумент функции тоже должен быть const, но это компилятор заставит, можно не задумываться. Если переменной не выполняется присвоение, то ее тоже можно отметить как const - быстрее будет работать, это касается аргументов функций. Однако в любой момент может потребовать доработка...
static - если это переменная в классе, то это редкий случай, даже редчайший. Если метод класса, то если в методе обрабатываются только аргументы этого метода и статические переменные класса, тоже редкий случай (впрочем, не такой и редкий, если просто для удобства в класс собирать функции).
пример бы, говорю же, с модификаторами вообще беда у меня
ЗЫ: тем более в инете вообще ужас что творится в обсуждении программирования - вот про const в прошлом месяце на хабре статья была, смысл - да не нужен этот const , вот смотрите ассемблерный код ничем не отличается что без const - компилятор все уберет (((
Вот пример:
Из Вашего кода непонятно зачем нужен интерфейс, поэтому я его выкинул.
Я конечно не знаю полностью Вашу задачу, но с вероятностью 99.99% он не нужен.
переучиваться с процедурного стиля? хм, хорошо написанный код в процедурном стиле обернуть в класс, если будет необходимость масштабировать проект, обычно не возникает проблем
делать много и быстро я умею,
это я решил посвятить изучению теории, вернее подтянуть MQL до того, что за последние годы появилось, даже тут многие не в курсе возможностей терминалов
а если изучать материал, то нужно его изучать правильно, имхо, ну и понять к чему ближе сейчас MQL к С++ или все таки C# , пока вроде к С++, в C# вообще народ не заморачивается с модификаторами, вернее, что студия пометит как сомнительно, максимум то и правят )))
Вот пример:
Из Вашего кода непонятно зачем нужен интерфейс, поэтому я его выкинул.
Я конечно не знаю полностью Вашу задачу, но с вероятностью 99.99% он не нужен.
по моему уже в 5-й раз слышу, мол выбрось интерфейсы и не заморачивайся )))
я взял за основу шаблон проектировании ООП "Стратегия"
применив, как указано, интерфейсы в качестве абстракции от которой я наследую базовый класс CStrategy - получилось, что у меня CStrategy будут отсутствовать публичные методы, все public описываются интерфейсами (3 шт = сама стратегия, завершение стратегии и вот теперь добавил запись состояния стратегии ). Роль интерфейсов... ну примерно та же самая, что у модификаторов const - получаешь на начальном этапе предупреждения, если не описал метод или попытаешься закрыть их наследованиями - пока больше удобства чем проблем испытываю.
В целом подтверждаю, что с вероятностью 100% он не нужен... но просто удобно, что класс CStrategy не содержит секции public
код Ваш качественно выглядит, после обеда воспроизведу у себя, попробую сравнить со своим
Спасибо!
Сам mql в основе имеет c++, но стараниями создателей в него внесли много плохого из шарпа, без добавления чего-либо хорошего из него. Показательна шарпоподобная стандартная библиотека. Более логичной она смотрелась бы, если бы была похожа на std. ИМХО.
возможно это я запустил фразу по форуму MQL "это не С++, это MQL ..." сейчас много отвечает на такие вопросы как Ваш в этом контексте ))))
в целом язык довольно демократичный, не удобно в MQL писать - "в 2 клика" можно уйти в .dll C++ и вот с начала года в .dll C# , если не изменяет память, то одна из первых статей по dll от Разработчика Рената - т.е. эта возможность изначально, как концепция продукта предлагается, имхо
ЗЫ: к написанному выше, почему то вспомнилась фраза - я художник - я так вижу! )))
ЗЫ: к написанному выше, почему то вспомнилась фраза - я художник - я так вижу! )))
вспоминается это очень часто в ответах разработчиков, хорошо это или плохо, не известно
еслиб разработчики давали информацию и закрывали раз и на всегда вопросы - почему нельзя добавить или изменить функцию
вспоминается это очень часто в ответах разработчиков, хорошо это или плохо, не известно
еслиб разработчики давали информацию и закрывали раз и на всегда вопросы - почему нельзя добавить или изменить функцию
ну это сложившийся корпоративный стиль общения юзера с поддержкой ИТ-монополистов, в инете полно случаев, где очевидные баги Майкрософт юзеры находят и после обращения в Майкрософт в ответ получают... обычно тишину )))
ЗЫ: из недавнего читанного, Хабр " Почему для открытия меню Windows читает один файл сто тысяч раз? "