Ошибки, баги, вопросы - страница 3397

[Artyom Trishkin]

A100 #:

В данном случае уместно будет запись в строку:

Объект может не создаться. Невалидный указатель в массиве тогда будет.

[A100]

Artyom Trishkin #:

Объект может не создаться. Невалидный указатель в массиве тогда будет.

Согласен - еще один аргумент против {} и мнимой лаконичности

Тем более, что создание одного объекта может зависеть от предыдущего и ошибка в 1ом наверняка должна препятствовать созданию остальных

C_Ind *inds[2];
C_Ind *ave0 = new C_AVE0(); if ( !(inds[0] = ave0) ) return;
C_Ind *ave1 = new C_AVE1(); if ( !(inds[1] = ave1) ) return;

return после обработки ошибки

[A100]

Здесь уже и макрос напрашивается:

#define MACRO(X) \
C_Ind  *ave##X = new C_AVE##X(); \
if ( !(inds[X] = ave##X) ) \
{                \
/*что делать в случае ошибки*/ \
    return;      \
}

C_Ind *inds[2];
MACRO(0);
MACRO(1);

[Andrey Dik]

A100 #:

Согласен - еще один аргумент против {} и мнимой лаконичности

Тем более, что создание одного объекта может зависеть от предыдущего и ошибка в 1ом должна препятствовать созданию остальных return после обработки ошибки

ага, здорово!

ретурн в инициализации советника. удобно работать таким образом, учитывая что таких сущностей-индикаторов несколько десятков.

[Aleksey Vyazmikin]

Зачем формируется шапка/рамка тут при использовании Стилизатора?

enum ENUM_vibros_type_NAME //Определяет метод преобразования выбросов
{
   type_Granica=0,//Значение выбросов преобразовываются в близкое к сплиту значение
   type_Random=1,//Значение выбросов преобразовываются в случайное значение в диапазоне вне выбросов
};
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
input ENUM_vibros_type_NAME Vibros_type=ENUM_vibros_type_NAME(0);//Метод выбора весов объектов

Мне она кажется явно лишней.

[A100]

Aleksey Vyazmikin #:

Зачем формируется шапка/рамка тут при использовании Стилизатора?

Мне она кажется явно лишней.

Если не хотите шапку, то теоретически можно так было бы написать:

input enum ENUM_vibros_type_NAME //Определяет метод преобразования выбросов
{
   type_Granica=0,//Значение выбросов преобразовываются в близкое к сплиту значение
   type_Random=1,//Значение выбросов преобразовываются в случайное значение в диапазоне вне выбросов
} Vibros_type = type_Granica;

Но в MQL почему то такая запись выдает ошибку !?

[A100]

Более того, даже такие записи (без input) выдают ошибку при компиляции:

static enum ENUM { //Error: 'ENUM' - enumeration cannot have modifiers
   a,
   b
} const e = a;

const enum ENUM { //Error: 'ENUM' - enumeration cannot have modifiers
   a,
   b
} e = a;

enum ENUM {
   a,
   b
} const e = a; //Error: 'const' - semicolon expected

[Aleksey Vyazmikin]

A100 #:

Если не хотите шапку, то теоретически можно так было бы написать:

Но в MQL почему то такая запись выдает ошибку !?

Я даже не понимаю, в чём логика добавлять шапку. Это же не функция, требующая какого то там описания.

[A100]

Aleksey Vyazmikin #:

Я даже не понимаю, в чём логика добавлять шапку. Это же не функция, требующая какого то там описания.

Стилизатором не пользуюсь, но шапку добавил бы: типы отдельно - данные отдельно. Исключение только если типы нигде больше не используются как например здесь, но как видите такая совмещенная запись в MQL не работает

[Aleksey Vyazmikin]

A100 #:

Стилизатором не пользуюсь, но шапку добавил бы: типы отдельно, данные отдельно. Исключение только если типы нигде больше не используются как например здесь

И что писали бы там в шапке и для чего?

Если компилятор предусматривает стандартные комментарии к внешним переменным.