Новая версия платформы MetaTrader 5 build 3320: Улучшения и исправления - страница 14
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В чем опасность, можно пояснить?
Задачи компиляторов давно перешагнули порог "компилировать без вопросов".
Они должны и занимаются поиском и предупреждением явно ошибочных действий программистов. При этом, классические компиляторы все равно на порядок отстают он систем статического анализа типа PVS Studio. Однократное его использование резко отрезвляет и показывает глубину пропасти между ворнингами компилятора и статического анализатора.
Не путайте частный случай "я в своих 100-500 строках то уж не ошибусь, чего меня поправляете" и реальные проекты с большим количеством кода, где такие слабости приводят к качественно бОльшим ошибкам. Тем более, что исправление элементарно.
Использование this в C++ является очень плохим вариантом и указывает на заведомую конфликтность в нейминге и областях видимости. По факту это костыль и прямое указание на наличие ошибок.
Задачи компиляторов давно перешагнули порог "компилировать без вопросов".
Они должны и занимаются поиском и предупреждением явно ошибочных действий программистов. При этом, классические компиляторы все равно на порядок отстают он систем статического анализа типа PVS Studio. Однократное его использование резко отрезвляет и показывает глубину пропасти между ворнингами компилятора и статического анализатора.
Не путайте частный случай "я в своих 100-500 строках то уж не ошибусь, чего меня поправляете" и реальные проекты с большим количеством кода, где такие слабости приводят к качественно бОльшим ошибкам. Тем более, что исправление элементарно.
Использование this в C++ является очень плохим вариантом и указывает на заведомую конфликтность в нейминге и областях видимости. По факту это костыль и прямое указание на наличие ошибок.
Ладно, задам вопрос еще раз, возможно я чего-то не понимаю.
У нас есть класс:
Вопрос, почему в обоих случаях мы получаем ворнинги:
Извините, может я не понимаю сакральный смысл ворнингов, того что мы хайдим переменную класса - переменной где-то в сигнатуре метода ниже, но получается, даже в случае верной инициализации мы получаем ворнинг и отвлекаемся на то, чтобы проверить что мы не жираф.
Разве это правильно? Если это правильно с вашей точки зрения, можно как-то отключить эти ворнинги?
Да, вы не понимаете. Да, вы кардинально ошибаетесь.
Слушайте специалистов.
Да, вы не понимаете. Да, вы кардинально ошибаетесь.
Слушайте специалистов.
Извините, а Вы могли бы дать не токсичный ответ в стиле "сам дурак, тебе надо сам и разбирайся", а быть более снисходительным и разъяснить, что я не понимаю и в чем кардинально ошибаюсь?
Если где-то в документации уже данные аспекты рассмотрены, буду благодарен за ссылки.
Я достаточно мягко объяснил в дополнение к ранее данным ответам другими разработчиками на предыдущей странице причины и обязанность компилятора не допускать заведомо опасные конструкции и потенциальное нарушение области видимости.
Сейчас 2022 год, а не дикие 1990 годы. Требования к качеству кода давно ужесточились и будут дальше ужесточаться. Качество важнее вольностей.
Не надо разыгрывать на публике карту "а что такого, я имею право ошибаться, имею право строить удивление, мне обязаны расжевать". Нет, не должны - объяснили, но расжевывать вы должны своим опытом, раз упорствуете в непонимании.
В теле метода можно упустить "this." при обращении к члену класса, особенно, когда код больше одной строки. Я вообще всегда предваряю переменные-члены префиксом "m_", т.к. привык с программирования под Андроид к такому.
Вася предваряет переменные-члены префиксом m_,
Петя предваряет переменные-члены префиксом v_,
Сережа предваряет переменные-члены префиксом w_
Вопрос: А зачем усложнять себе и другим жизнь, когда есть универсальный и единственно правильный способ обойтись вообще без префиксов?
Какой? Вот подсказка
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Вопросы по ООП в MQL5
fxsaber, 2019.07.07 14:29
По этой же причине использую всегда this для однозначности и читабельности.
ВСЕГДА (!). Другими словами this - это и есть универсальный префикс. Теперь по новому взгляните на мир и попробуйте вновь ответить на этот вопрос
Вывод: запись
единственно правильная, а все эти warning и префиксы - это от зашоренности мышления, и если вы (в широком смысле) не можете на простом примере объяснить их необходимость, то
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
MT5 и скорость в боевом исполнении
A100, 2020.05.31 23:47
Уйму не нужно, потому что согласно Теории простоты Эйнштейна: "Если вы не можете объяснить это просто - значит, вы сами не понимаете этого до конца"
ВСЕГДА (!). Другими словами this - это и есть универсальный префикс. Теперь по новому взгляните на мир и попробуйте вновь ответить на этот вопрос
Вывод: запись
единственно правильная, а все эти warning и префиксы - это от зашоренности мышления, и если вы (в широком смысле) не можете на простом примере объяснить их необходимость, то
Очень хорошо и полезно, когда вы находите ошибки и неоднозначности в MQL5. Это очень помогает всем нам.
Но не дай бог, если вы с такими неоднозначностями пишите боевой код. В профессиональных больших проектах вас просто выгонят и правильно сделают.
С this вы продемонстрировали осознанный самострел с последующим корявым исправлением, не говоря уже о тотальном замусоривании кода.
Возьмите MSVC с ключом /analyze и включением 4 уровня ворнингов, CLang со всеми ворнингами, PVS Studio и погоняйте на проекте со своими вольными подходами. Вы увидите чудовищную разницу между обычным стеснительным выводом компилятора в угоду "ну это же разрешено и вообще мы компиляем легаси код по факту" и тем, что на самом деле думает компилятор об обрабатываемых исходниках. В реальности C++ компиляторы своим мнением боятся приводить в бешенство программистов, а программисты боятся включать все ворнинги - всем приятнее закрывать глаза на проблемы.
У нас нет режима стеснения, как и необходимости в 99% случаев компилять легаси код. Поэтому мы сразу показываем предупреждения о неправильных практиках. Благо, исправление копеечное.
Не забывайте, это финансовый код и к нему в разы(на самом деле на порядок) выше требования к качеству кода.
Свою первую программу на C я написал в 1990 году, затем через мои руки прошел десяток брендов C/C++ компиляторов, воочию все годы наблюдал беспредел и беспомощность компиляторов, рост их качества, писал и пишу программы все эти годы, боролся за качество нашего кода, радовался и использовал растущие механизмы контроля качества кода, развивал поколения MQL и работал над крешами.Вася предваряет переменные-члены префиксом m_,
Петя предваряет переменные-члены префиксом v_,
Сережа предваряет переменные-члены префиксом w_
Выше дали ссылку на обсуждение трехлетней давности. Прочел - понравилось объяснение. Приведу его здесь.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Вопросы по ООП в MQL5
Igor Makanu, 2019.07.07 14:19
если не затруднит, то зачем тут используем " :: " https://www.mql5.com/ru/docs/basis/operations/other
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Вопросы по ООП в MQL5
fxsaber, 2019.07.07 14:29
Иначе мне придется проверять, что в родительских классах нет одноименного метода. А даже если и нет, то если кто-то его добавит, код все равно останется рабочим.
По этой же причине использую всегда this для однозначности и читабельности.
ЗЫ Но в некоторых редких ситуациях :: и this лишают гибкости. Тут похожие тонкости на то, когда лучше писать тело метода внутри класса, а когда - снаружи. Помню, что со всем этим сталкивался, но примеров не приведу.
Выделил цветом причину обязательного "замусоривания" кода. В кодобазе такой "замусоренный" код и выкладываю. Мне он значительно понятнее при чтении, чем СБ.
Например, вот читаю кусок штатного файла MQL5\Include\Trade\Trade.mqh:
Можете понять при чтении, что за OrderSend вызывается?
Выше дали ссылку на обсуждение трехлетней давности. Прочел - понравилось объяснение. Приведу его здесь.
Выделил цветом причину обязательного "замусоривания" кода. В кодобазе такой "замусоренный" код и выкладываю. Мне он значительно понятнее при чтении, чем СБ.
Например, вот читаю кусок штатного файла MQL5\Include\Trade\Trade.mqh:
Можете понять при чтении, что за OrderSend вызывается?
Это системная функция языка. Считаю, что переназначать системные функции/константы очень плохая идея мягко говоря, а грубо говоря - высшая степень садомазохизма)) А Вы любитель дефайнить всё что дефайниться и даже что не дифайнется тоже умудряетесь.)