Новая версия платформы MetaTrader 5 build 3320: Улучшения и исправления - страница 14

Новый комментарий
 
White Rabbit #:

В чем опасность, можно пояснить?

Задачи компиляторов давно перешагнули порог "компилировать без вопросов".

Они должны и занимаются поиском и предупреждением явно ошибочных действий программистов. При этом, классические компиляторы все равно на порядок отстают он систем статического анализа типа PVS Studio. Однократное его использование резко отрезвляет и показывает глубину пропасти между ворнингами компилятора и статического анализатора.

Не путайте частный случай "я в своих 100-500 строках то уж не ошибусь, чего меня поправляете" и реальные проекты с большим количеством кода, где такие слабости приводят к качественно бОльшим ошибкам. Тем более, что исправление элементарно.

Использование this в C++ является очень плохим вариантом и указывает на заведомую конфликтность в нейминге и областях видимости. По факту это костыль и прямое указание на наличие ошибок.

 
Renat Fatkhullin #:

Задачи компиляторов давно перешагнули порог "компилировать без вопросов".

Они должны и занимаются поиском и предупреждением явно ошибочных действий программистов. При этом, классические компиляторы все равно на порядок отстают он систем статического анализа типа PVS Studio. Однократное его использование резко отрезвляет и показывает глубину пропасти между ворнингами компилятора и статического анализатора.

Не путайте частный случай "я в своих 100-500 строках то уж не ошибусь, чего меня поправляете" и реальные проекты с большим количеством кода, где такие слабости приводят к качественно бОльшим ошибкам. Тем более, что исправление элементарно.

Использование this в C++ является очень плохим вариантом и указывает на заведомую конфликтность в нейминге и областях видимости. По факту это костыль и прямое указание на наличие ошибок.

Ладно, задам вопрос еще раз, возможно я чего-то не понимаю.
У нас есть класс:

class A {
private:
    int a;
    int b;
public:
    A(int a, int b) {
        a = a; // переменная а будет присвоена самой себе, абсурдно, но это для примера. Приватное поле а - останется с "мусором"
        this.b = b; // приватное поле b будет проинициализированно аргументом b из параметров конструктора
    }
};

Вопрос, почему в обоих случаях мы получаем ворнинги:

declaration of 'a' hides member A.mqh   14      11
see previous declaration of 'a'	A.mqh	8	9
declaration of 'b' hides member A.mqh   14      18
see previous declaration of 'b'	A.mqh	9	9

Извините, может я не понимаю сакральный смысл ворнингов, того что мы хайдим переменную класса - переменной где-то в сигнатуре метода ниже, но получается, даже в случае верной инициализации мы получаем ворнинг и отвлекаемся на то, чтобы проверить что мы не жираф.

Разве это правильно? Если это правильно с вашей точки зрения, можно как-то отключить эти ворнинги?

 

Да, вы не понимаете. Да, вы кардинально ошибаетесь.

Слушайте специалистов.

 
Renat Fatkhullin #:

Да, вы не понимаете. Да, вы кардинально ошибаетесь.

Слушайте специалистов.

Извините, а Вы могли бы дать не токсичный ответ в стиле "сам дурак, тебе надо сам и разбирайся", а быть более снисходительным и разъяснить, что я не понимаю и в чем кардинально ошибаюсь?

Если где-то в документации уже данные аспекты рассмотрены, буду благодарен за ссылки. 

 

Я достаточно мягко объяснил в дополнение к ранее данным ответам другими разработчиками на предыдущей странице причины и обязанность компилятора не допускать заведомо опасные конструкции и потенциальное нарушение области видимости.

Сейчас 2022 год, а не дикие 1990 годы. Требования к качеству кода давно ужесточились и будут дальше ужесточаться. Качество важнее вольностей.

Не надо разыгрывать на публике карту "а что такого, я имею право ошибаться, имею право строить удивление, мне обязаны расжевать". Нет, не должны - объяснили, но расжевывать вы должны своим опытом, раз упорствуете в непонимании.

 
Sergey Gridnev #:
В теле метода можно упустить "this." при обращении к члену класса, особенно, когда код больше одной строки. Я вообще всегда предваряю переменные-члены префиксом "m_", т.к. привык с программирования под Андроид к такому.

Вася предваряет переменные-члены префиксом m_,

Петя предваряет переменные-члены префиксом v_,

Сережа предваряет переменные-члены префиксом w_

Вопрос: А зачем усложнять себе и другим жизнь, когда есть универсальный и единственно правильный способ обойтись вообще без префиксов?

Какой? Вот подсказка

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Вопросы по ООП в MQL5

fxsaber, 2019.07.07 14:29

По этой же причине использую всегда this для однозначности и читабельности.

ВСЕГДА (!). Другими словами this - это и есть универсальный префикс. Теперь по новому взгляните на мир и попробуйте вновь ответить на этот вопрос

Вывод: запись

class A {
    int a;
public:
    A(int a) { this.a = a; }
};

единственно правильная, а все эти warning и префиксы - это от зашоренности мышления, и если вы (в широком смысле) не можете на простом примере объяснить их необходимость, то

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

MT5 и скорость в боевом исполнении

A100, 2020.05.31 23:47

Уйму не нужно, потому что согласно Теории простоты Эйнштейна: "Если вы не можете объяснить это просто - значит, вы сами не понимаете этого до конца"

 
A100 #:


ВСЕГДА (!). Другими словами this - это и есть универсальный префикс. Теперь по новому взгляните на мир и попробуйте вновь ответить на этот вопрос

Вывод: запись

единственно правильная, а все эти warning и префиксы - это от зашоренности мышления, и если вы (в широком смысле) не можете на простом примере объяснить их необходимость, то

Очень хорошо и полезно, когда вы находите ошибки и неоднозначности в MQL5. Это очень помогает всем нам.

Но не дай бог, если вы с такими неоднозначностями пишите боевой код. В профессиональных больших проектах вас просто выгонят и правильно сделают.

С this вы продемонстрировали осознанный самострел с последующим корявым исправлением, не говоря уже о тотальном замусоривании кода.


Возьмите MSVC с ключом /analyze и включением 4 уровня ворнингов, CLang со всеми ворнингами, PVS Studio и погоняйте на проекте со своими вольными подходами. Вы увидите чудовищную разницу между обычным стеснительным выводом компилятора в угоду "ну это же разрешено и вообще мы компиляем легаси код по факту" и тем, что на самом деле думает компилятор об обрабатываемых исходниках. В реальности C++ компиляторы своим мнением боятся приводить в бешенство программистов, а программисты боятся включать все ворнинги - всем приятнее закрывать глаза на проблемы.

У нас нет режима стеснения, как и необходимости в 99% случаев компилять легаси код. Поэтому мы сразу показываем предупреждения о неправильных практиках. Благо, исправление копеечное.

Не забывайте, это финансовый код и к нему в разы(на самом деле на порядок) выше требования к качеству кода.


Свою первую программу на C я написал в 1990 году, затем через мои руки прошел десяток брендов C/C++ компиляторов, воочию все годы наблюдал беспредел и беспомощность компиляторов, рост их качества, писал и пишу программы все эти годы, боролся за качество нашего кода, радовался и использовал растущие механизмы контроля качества кода, развивал поколения MQL и работал над крешами. 

Если не согласны, то продолжайте писать как хотите - наше мнение по контролю качества кода я уже десяток раз высказывал. Оно не изменится.
 
A100 #:

Вася предваряет переменные-члены префиксом m_,

Петя предваряет переменные-члены префиксом v_,

Сережа предваряет переменные-члены префиксом w_


Если такое происходит в команде, надо избавиться от некоторых ее членов.

Повсеместное использование "this." значитально замусоривает код. Префиксы тоже замусоривают, но согласитесь, даже двухсимвольный префикс мусорит меньше пятисимвольного "this.'
 
Sergey Gridnev #:
Повсеместное использование "this." значитально замусоривает код.

Выше дали ссылку на обсуждение трехлетней давности. Прочел - понравилось объяснение. Приведу его здесь.

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Вопросы по ООП в MQL5

Igor Makanu, 2019.07.07 14:19

fxsaber:
virtual bool      Load( const int file_handle )
   {
     ::ResetLastError();
    

если не затруднит, то зачем тут используем " ::    "   https://www.mql5.com/ru/docs/basis/operations/other  

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

Вопросы по ООП в MQL5

fxsaber, 2019.07.07 14:29

Иначе мне придется проверять, что в родительских классах нет одноименного метода. А даже если и нет, то если кто-то его добавит, код все равно останется рабочим.

По этой же причине использую всегда this для однозначности и читабельности.


ЗЫ Но в некоторых редких ситуациях :: и this лишают гибкости. Тут похожие тонкости на то, когда лучше писать тело метода внутри класса, а когда - снаружи. Помню, что со всем этим сталкивался, но примеров не приведу.

Выделил цветом причину обязательного "замусоривания" кода. В кодобазе такой "замусоренный" код и выкладываю. Мне он значительно понятнее при чтении, чем СБ.


Например, вот читаю кусок штатного файла MQL5\Include\Trade\Trade.mqh:

//+------------------------------------------------------------------+
//| Delete specified pending order                                   |
//+------------------------------------------------------------------+
bool CTrade::OrderDelete(const ulong ticket)
  {
//--- check stopped
   if(IsStopped(__FUNCTION__))
      return(false);
//--- clean
   ClearStructures();
//--- setting request
   m_request.action    =TRADE_ACTION_REMOVE;
   m_request.magic     =m_magic;
   m_request.order     =ticket;
//--- action and return the result
   return(OrderSend(m_request,m_result));
  }

Можете понять при чтении, что за OrderSend вызывается?

 
fxsaber #:

Выше дали ссылку на обсуждение трехлетней давности. Прочел - понравилось объяснение. Приведу его здесь.

Выделил цветом причину обязательного "замусоривания" кода. В кодобазе такой "замусоренный" код и выкладываю. Мне он значительно понятнее при чтении, чем СБ.


Например, вот читаю кусок штатного файла MQL5\Include\Trade\Trade.mqh:

Можете понять при чтении, что за OrderSend вызывается?

Это системная функция языка. Считаю, что переназначать системные функции/константы очень плохая идея мягко говоря, а грубо говоря - высшая степень садомазохизма)) А Вы любитель дефайнить всё что дефайниться и даже что не дифайнется тоже умудряетесь.)

1...7891011121314151617181920
Новый комментарий
Причина обращения: