Как грамотно и правильно собрать сова? [стиль MQL5] - страница 4

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

Комментарии - недавно была хорошая статья на Хабре, где мне понравилась мысль - "В комментариях должно быть написано не ЧТО здесь сделано, а ПОЧЕМУ это сделано именно так".

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

 
TheXpert:
Ну я чего спросил... Я его просто пипец как редко использую и явно оно нужно чаще всего только лишь в выражениях типа return *this.

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

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

 
Laryx:

Да, я тоже не вполне понимаю, зачем в вышеприведенном коде this 

А зачем в Вашем примере после while() { ... }; точка с запятой Вы понимаете? и можете объяснить?

Синтаксис языка это не вопрос понятий, а вопрос правил, и они должны выполняться! 

 
A100:

А зачем в Вашем примере после while() { ... }; точка с запятой Вы понимаете? и можете объяснить?

Синтаксис языка это не вопрос понятий, а вопрос правил, и они должны выполняться! 

Я не спорю. Но в конкретно вашем примере, вы у указателя текущего класса вызываете через селектор указатель переменную вместе с оператором разрешения контекста.  В документации не описан приоритет операции получения контекста - поэтому в приведенном вами примере неясно - то ли это у this вызывается указатель на класс А, и берется переменная из этого класса (А.А), то ли сперва берется переменная в классе А, и потом по указателю this происходит обращение к переменной класса А. Второй случай, видимо, вы и имели ввиду, и он вроде как правильный.

Но само написание такого двусмысленного кода, как мне кажется - весьма опасно.

 
Там всё однозначно. С++ даже предупреждений не выдает. Но для Вас это наверное не аргумент.
 
Laryx:

А я несколько раз встречался с ситуацией, когда этот код в строгой венгерской нотации должен был быть написан так:

byte btA;

...

integer iB;

...

while (btА < iB)

    {

    ....

    ++btA;

    };

...

Убивать на месте. А затем увольнять без выходного пособия. К сожалению С++ позволяет писать такие извраты, но это не значит что все должны становиться извращенцами.
 
C-4:
Убивать на месте. А затем увольнять без выходного пособия. К сожалению С++ позволяет писать такие извраты, но это не значит что все должны становиться извращенцами.

Ну-ну. Это я ради примера написал такой маленький цикл. А реально - переменная btA может быть получена от одного интерфейса, к которому ты не имеешь доступа, а переменная iB - от совсем другого, причем оба они экспортируются DLL'ами, к исходному коду которых доступа нет. Плюс между получением переменных и внутри цикла - весьма много действий, а инкрементация btA происходит внутри многих блоков кода. И если бы не такая нотация - очень легко можно было бы упустить из виду возможное переполнение.  Если на память нет ограничений - то все решается очень просто - обе полученных переменных записываются во внутренние переменные int (или даже long), и потом можно не опасаться переполнений. Но вот если память ограниченна, а подобных переменных - сотни, то приходится оставлять значения в тех форматах, в которых они получены, и просто помнить о возможности переполнений.

 
Laryx:

... Если на память нет ограничений - то все решается очень просто - обе полученных переменных записываются во внутренние переменные int (или даже long), и потом можно не опасаться переполнений. Но вот если память ограниченна, а подобных переменных - сотни, то приходится оставлять значения в тех форматах, в которых они получены, и просто помнить о возможности переполнений. 

Вот Вы и сами решили несуществующую проблему. На самом деле, есть хоть один пример для PC, где экономия 1 байта памяти существенно на что-либо влияла? Кое-кто уже попытался поэкономить память введя CopyBuffer в MQL5. Печальный результат известен всем - тестер МТ5 работает существенно медленнее своего аналога МТ4. И если проблемы с нехваткой памяти решаются элементарно - покупкой еще одной плашки за 700р. то проблемы производительности простого и дешевого решения не имеют в принципе. Вот и думайте, так ли уж нужен вам этот байт платить за который придется новыми глюками и снижением производительности.
 
C-4:
Вот и думайте, так ли уж нужен вам этот байт платить за который придется новыми глюками и снижением производительности.

Именно про это я и говорю - венгерская нотация - вовсе не так уж бесполезна. 

Не говоря уж о том, что это хорошо, когда у вас просто "еще одна плашка за 700р", и продукт - это робот на MQL. Однако, это не все случаи использования венгерской нотации.

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

12345
Новый комментарий