Будущее MQL5 - MQL5+ или даже MQL6 - страница 9

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

Mihail Matkovskij:

И хоть их можно обойти, но, вопрос, зачем, если в других современных ЯП подобных проблем попросту нет?

В других ЯП по другому всё организовано. Например, в Java нет глобальных переменных и констант, но вместо них можно использовать статические переменные объявленных классов. Но суть от этого не меняется, поскольку, если указать имя статической переменной, которая дублируется в разных классах, то компилятор попросит уточнить имя пакета и класса, к которому она принадлежит, т.к. процесс компиляции не обладает телепатическими способностями. Точно также и с классами. Если указать имя класса или интерфейса, которое дублируется в разных пакетах, то компилятор опять же попросит уточнить название пакета.
 
Mihail Matkovskij:

 И хоть ошибка не критичная, но всё равно неудобно. 

Да это и не ошибка, так.. нотификация скорее.  В некоторых языках никаких нотисов подобного рода даже нет. Что-то в локальной области перекрыло что-то уровнем выше ну и ладно. Значит так задумано. Хотя в некоторых случаях такое предупреждение весьма полезно.

Например в MQL глобальные переменные даже не при чем, и моя рекомендация их не использовать тоже побоку, например:

Создаем несколько областей видимости:

 

int OnInit()
  {
        int i = 10;
        {
                int i =5;
                {
                        int i = 0;
                }
        }
   return(INIT_SUCCEEDED);
  }

И караул, получаем аж 2 предупреждения.

declaration of 'i' hides local declaration at line 3    
declaration of 'i' hides local declaration at line 5    

 

Отсюда вывод -

1) не обращать внимания на предупреждения такого рода
2) не делать одинаковых имен в областях видимости ниже/выше
3) убедить сервисдеск убрать эту нотификацию как бесполезную

 
Igor Volodin:

3) убедить сервисдеск убрать эту нотификацию как бесполезную

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

 
Mihail Matkovskij:

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

Переменная point сообщает цену 1 пункта и является заменой стандартному Point. Функция MarketInfo(EA_Symbol(), MODE_POINT) даёт цену 1 пункта любого инструмента. Далее, переменную point можно использовать в любой функции, в теле советника, если она является глобальной переменной конечно же. Согласитесь что, подобные случаи вызывают определённые неудобства и довольно часто (если вы конечно имеете опыт программирования на MQL). И хоть их можно обойти, но, вопрос, зачем, если в других современных ЯП подобных проблем попросту нет?

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

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

Ну а всем остальным рекомендую радоваться такому уровню помощи компилятора и исправлять свои ошибки. Это реальные места потенциальных ошибок и именно начинающим разработчикам это критически важно для обучения. 

 

Цветовых схем охото. Что бы не только в редакторе цвет текста и фона менялся, но и в остальных окнах.

 

Что бы член-данные класса не красились в цвет инпут-перменных при совпадении имен.

 

Уже несколько раз, заканчивая рабочий день, и закрывая окна программ, броузеров и т.п., случайно закрывал и работающий в режиме оптимизации терминал МТ5. Т.о. все результаты пропадали. Перезапуск начинает все с начала.

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

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

 
Igor Volodin:

Да это и не ошибка, так.. нотификация скорее.  В некоторых языках никаких нотисов подобного рода даже нет. Что-то в локальной области перекрыло что-то уровнем выше ну и ладно. Значит так задумано. Хотя в некоторых случаях такое предупреждение весьма полезно.

Например в MQL глобальные переменные даже не при чем, и моя рекомендация их не использовать тоже побоку, например:

Создаем несколько областей видимости:

 

И караул, получаем аж 2 предупреждения.

 

Отсюда вывод -

1) не обращать внимания на предупреждения такого рода
2) не делать одинаковых имен в областях видимости ниже/выше
3) убедить сервисдеск убрать эту нотификацию как бесполезную

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

Здесь я вижу 2 варианта решения проблемы.

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

2. Если разработчики не желают менять синтаксис, ввести правило объявления параметров в функциях, на подобии полей классов, например, имена параметров должны начинаться на i либо i_ (от алгл. Input) и исправить таким образом все параметры в стандартных модулях

 

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

Выход только один: не допускайте перекрытия переменных и не пытайтесь сохранить право совершать ошибки с требованием к остальным уважать это право.

 
Renat Fatkhullin:

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

Выход только один: не допускайте перекрытия переменных и не пытайтесь сохранить право совершать ошибки с требованием к остальным уважать это право.

Вероятно, вы меня не правильно поняли. Я ни от кого ничего не требую, а всего лишь даю советы о том, как сделать MQL более удобным в использовании.
12345678910111213
Новый комментарий
Причина обращения: