Прощаи робот-да здравствует маразм - страница 8

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

Локальные переменные и параметры находятся в одной области видимости, поэтому - неважно, параметр имеет такое имя или локальная переменная, но в любом случае это имя скрывает имя во внешней области видимости.

Не в любом. При передаче переменной по ссылке, локальной копии не создается и работа производится непосредственно с переданной переменной. Так какое сокрытие тут происходит?
 
Andrei01:
Не в любом. При передаче переменной по ссылке, локальной копии не создается и работа производится непосредственно с переданной переменной. Так какое сокрытие тут происходит?

Здесь происходит сокрытие имён. Всё остальное, - копия, не копия, - вторично. Внутри функции при использовании имени ссылки работа будет происходить с тем объектом, на который ссылается ссылка. Если она ссылается на объект во внешней области видимости, то работа будет происходить с ним. Но не потому, что отсутствует сокрытие имени, - сокрытие, как раз, точно так же, как и в других случаях, присутствует, - а потому, что ссылка указывает на этот объект. Вызвали так функцию. Передали именно этот объект по ссылке, и она на него теперь указывает. При вызове и передаче в момент вызова другого объекта, тот же самый код функции будет работать уже с другим объектом.

Я же приводил пример с именем типа и именем переменной, то есть, с максимально различными по природе сущностями, чтобы, таким образом, показать, что сокрытие применяется/относится именно к именам, а всё остальное - уже вторично.

Однако, пытаясь составить ещё один пример на эту тему на MQL4++, случайно обнаружил, что, оказывается, для параметров в MQL4++ создаётся дополнительная область видимости. А область видимости локальных переменных уже в неё вложена:

#property strict

void f(int a) {
  int saved = a;
  int a = a + 1;

  Print("saved = " , saved, ", a = ", a);
}

void OnStart() {
  f(3);
}

Данный пример КОМПИЛИРУЕТСЯ с характерным предупреждением:

declaration of 'a' hides local declaration at line 3    3.mq4   5       7

И в дальнейшем успешно исполняется:

23:52:22 Script 3 EURUSDm,H1: loaded successfully
23:52:22 3 EURUSDm,H1: initialized
23:52:22 3 EURUSDm,H1: saved = 3, a = 4
23:52:22 3 EURUSDm,H1: uninit reason 0
23:52:22 Script 3 EURUSDm,H1: removed

Очевидно, что в MQL4++ для параметров создана ещё одна "прослоечная" область видимости. Именно поэтому удаётся объявить локальную переменную с именем, совпадающим с именем параметра.

В C/C++ такая "прослойка" отсутствует:

void f(int a) {
  int saved = a;
  int a = a + 1;
}

Компилятор популярно объясняет, что в данной области видимости уже есть переменная с таким именем:

$ icpc -c 1.cpp
1.cpp(3): error: "a" has already been declared in the current scope
    int a = a + 1;
        ^

То есть, область видимости параметров функции и её локальных переменных - одна и та же.

Почему в MQL4++ это - не так, для какой такой цели, - вопрос, конечно, интересный...

 
simpleton:

void f(int a)

Данный пример КОМПИЛИРУЕТСЯ с характерным предупреждением:

В данном случае обсуждается случай передачи переменной по ссылке и ошибочного предупреждения, а не создание локальной копии.

void f(int& a)
 

Читал только первых несколько постов.

Конечно не совсем гладко всё идёт и под мат. Здесь некоторые упущения разработчиков в тестировании продукта, который доходит до конечного пользователя. Однако и МТ4 не силён в мультивалютных стратегиях (тестирование), а надо, надо доработать. Так что я всё-таки надеюсь, что это будет когда-нибудь..

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

Удачи!


 
Andrei01:

В данном случае обсуждается случай передачи переменной по ссылке и ошибочного предупреждения, а не создание локальной копии.

void f(int& a)

С точки зрения сути предупреждения, это - неважно. Более того, неважно не только то, по ссылке или по значению передаётся переменная, но и какого она типа:

#property strict

int a; // line 3
class A { };
void f(A *&a) { } // line 5
void OnStart() { }

Код компилируется, выдаётся обсуждаемое предупреждение:

declaration of 'a' hides global declaration at line 3   3.mq4   5       12

Вы почему-то не хотите этого понять.

Предупреждение само по себе нисколько не ошибочно. Более того, навскидку, отслеживание областей видимости в MQL4++ сделано на удивление добротно по сравнению с тем, как сделаны другие вещи.

Предупреждение, хоть и верно, но не практично, и при этом его нельзя отключить, - вот, в чём всё дело. А отнюдь не в передаче по ссылке.

 
simpleton:

С точки зрения сути предупреждения, это - неважно. Более того, неважно не только то, по ссылке или по значению передаётся переменная

Есть большая разница по сути предупреждения между передачей самой переменной и её модификацией в функции и создание её копии, а сама переменная остается неизменной.

Ну а то что предупреждения нельзя отключить или настроить под себя, то это ведь классический фирменный стил МК - "не пущать":)) С этим ничего поделать нельзя а лишь низменно и смиренно принять так как этот стиль возведен в разряд религиозного атрибута... логику и справедливость хоть какую-то тут бесполезно искать как показывает практика. ))

 

Тьфу тьфу у меня все метаквотовское работает как часы

никаких нареканий нет вообще. 

 
simpleton:

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

... 

Вот люди чудаки. Борются такие донкихоты с компилятором как с ветряной мельницей не понимая главного: компилятор ваш союзник! Радуйтесь, что компилятор ругается на потенциально опасные участки кода. Радуйтесь даже тогда, когда приложение вылетает сразу после запуска с указанием строки ошибки. Но не дай вам бог получить неуправляемый код, когда ошибок и предупреждений никаких нет, и программа работает внешне нормально, но время от времени начинают появляться странные глюки, причина которых нигде не прослеживается. В такие моменты покрываешься испаренной и начинаешь мечтаешь об ошибках типа "invalid pointer" или "деления на ноль".
 
C-4:
Но не дай вам бог получить неуправляемый код, когда ошибок и предупреждений никаких нет, и программа работает внешне нормально, но время от времени начинают появляться странные глюки, причина которых нигде не прослеживается. В такие моменты покрываешься испаренной и начинаешь мечтаешь об ошибках типа "invalid pointer" или "деления на ноль".

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

Функциональные проверки кода к компилятору отношения никакого не имеют и нет смысла это от него ожидать изначально.

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

 
Andrei01:

Есть большая разница по сути предупреждения между передачей самой переменной и её модификацией в функции и создание её копии, а сама переменная остается неизменной.

Здесь просто предупреждение другого типа. О сокрытии имён.

А сама переменная не передаётся. Передаётся ссылка на неё.

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