Предложение - явное приведение к datetime

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

Для повышения качества программ и снижения ошибок предлагаю запретить неявный кастинг к типу datetime, т.к. это специфический тип, предназначенный для строго определённой цели, поэтому безконтрольно смешивать его с другими типами считаю недопустимым:

void f(datetime time)  { }

void Main()
{
  bool a = 0;
  f(a);  // Нет ни ошибки, ни даже предупреждения компилятора
}

А когда функция имеет много аргументов, то вероятность случайной ошибки существенно возрастает.   Например, у меня такое случается при использовании CopySeries и CopyRates.  Перепутал местами параметр времени - и выискивай потом ошибку...

Дабы не создавать трудностей имеющимся кодам (пусть и кривым), предлагаю активировать такой запрет только при использовании директивы strict.

 

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

 

Одно другое не исключает.

Я также считаю, что необходимо ввести предупреждение о неявном приведении типов.

 
А как вы себе представляете решение этой проблемы? Не получится-ли так, что на любое неявное приведение типов будет предупреждение? Да плюс ко всему надо внимательно разобраться с типом bool и datetime. Ох как они похожи на int, а вы не пробовали подсунуть туда тип double? Может и предупреждение будет? Я не обращал особого внимания, но какие-то предупреждения были. И ещё, когда вводишь переменные в вызов функции, то выбор переменной возможен только того типа который предусмотрен функцией. А список совместимых переменных появляется после третьей буквы, по умолчанию, я себе настроил после двух. А вот в предложенном примере в имени переменной только одна буква.
 
Alexey Navoykov:

Передача по ссылке может иногда помочь избежать Вам таких ошибок.


Единственное отличие datetime от long - это приведение к типу string. Так что логично отсутствие предупреждений.

 
Alexey Viktorov:
А как вы себе представляете решение этой проблемы? Не получится-ли так, что на любое неявное приведение типов будет предупреждение?

На мой взгляд, так и должно быть. ЛЮБОЕ неявное преобразование типов должно вызывать предупреждение. Оно вас же потом выручит, когда вы случайно подсунете, скажем, переменной long значение int. А потом будете удивляться, откуда возникают ошибки на пяти миллиардах. Когда же вам компилятор выдаст предупреждение - вы сразу обратите внимание, что в int пяти миллиардов не бывает.

 
fxsaber:

Передача по ссылке может иногда помочь избежать Вам таких ошибок.

Единственное отличие datetime от long - это приведение к типу string. Так что логично отсутствие предупреждений.

С точки зрения структуры значения - все верно, datetime - это все тот же long. Но, с точки зрения логики - это разные типы, и предупреждение, по-моему, должно быть.

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

 
Georgiy Merts:

С точки зрения структуры значения - все верно, datetime - это все тот же long. Но, с точки зрения логики - это разные типы, и предупреждение, по-моему, должно быть.

Это не разные типы, а один и тот же. Посмотрите Template.tpl, где datetime в инпутах.

Так же можете посмотреть поля MqlParam-структуры.

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

В таком случае никаких предупреждений быть не должно. А вот если наоборот - будет.

Документация по MQL5: Константы, перечисления и структуры / Структуры данных / Структура входных параметров индикатора
Документация по MQL5: Константы, перечисления и структуры / Структуры данных / Структура входных параметров индикатора
  • www.mql5.com
каждого элемента этого массива указывает тип данных, передаваемых данным элементом. Сами значения параметров индикатора необходимо предварительно поместить в соответствующие поля каждого элемента (в...
 
fxsaber:

Это не разные типы, а один и тот же. Посмотрите Template.tpl, где datetime в инпутах..

Да я знаю, что это "один и тот же тип".

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

fxsaber:

В таком случае никаких предупреждений быть не должно. А вот если наоборот - будет.

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

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

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

 
Georgiy Merts:

Да я знаю, что это "один и тот же тип".

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

Выступаю против этого предложения.


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

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

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


При таком раскладе никаких проблем не должно быть.

 
fxsaber:

Выступаю против этого предложения.

При таком раскладе никаких проблем не должно быть.

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

В данном случае - ситуация схожая. Или такой пример. Какой-нибудь ID, в котором разряды старше 32 что-то обозначают. Процедура написана, все нормально работает. А потом - я ее решил использовать, забыв про старшие разряды, передав ей uint. Процедура-то ждет, что в старших разрядах есть информация, а в инте - ее нет. И вылезти проблема может далеко не сразу.

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