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

Новый комментарий
 
fxsaber # :
Просьба объяснить логику такого поведения компилятора.

Зачем ему требуется удалять штатный оператор присваивания при наличии const-полей?


ЗЫ Поиск выдал упоминание только в книге . Но там нет пояснения.

Это ошибка компилятора. Не следует использовать присваивание (operator=), а следует использовать конструктор Copy.
 
Vladislav Boyko # :

Есть кое-что немного похожее в документации.

Можно трактовать так, что компилятор удалил оператор копирования для класса B, так как нет возможности скопировать объект класса A, который является членом класса B. В этом я вижу аналогию с вашим примером - там нет возможности скопировать Tmp, так как он константный.

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

Не то же самое. Там ошибка ожидаема, так как это присваивание, и, кроме того, в A определен явный 'operator='.
 
Alain Verleyen #:
а следует использовать конструктор Copy

Если определен явный конструктор копирования, то он будет вызван

struct A
{
  const int Tmp;
  A(const A& x) : Tmp(x.Tmp) {}
  A(int x) : Tmp(x) {}
};

void OnStart()
{
  //A a1 = {7}; // 'a1' - cannot be initialized with initializer list
  A a1(7);
  Print(a1.Tmp);
  A a2 = a1; // OK
  Print(a2.Tmp);
}

Я не знаю, следует ли компилятору генерировать неявный конструктор копирования в таком случае. Я не программирую на C++, поэтому я не знаю, какое поведения компилятора считается правильным.

Alain Verleyen #:
Не то же самое. Там ошибка ожидаема, так как это присваивание, и, кроме того, в A определен явный 'operator='.

Да, вы правы, я не заметил, что там присваивание, а не инициализация.

 

После сегодняшнего множественного апдейта иногда вот такая ошибка проскакивала, сфоткал её:




 
Загрузил в МТ4 котировки фьючерса, старая история сильно битая с пропусками баров. 
Сейчас столкнулся с такой проблемой - МТ4 'не видит' некоторые соседние бары в Тестере.
Именно некоторые, т.к. в других ситуациях пропуски баров проблемой не является.

В самом начале после start() вывожу строки:
Print("");
Print("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");
Print("Time[0] = ", Time[0] );
Print("Time[1] = ", Time[1] );
Print("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@");



Bar[1] - Время 23:49:







Bar[0] следующий за Bar[1] - Время 10:30:



Но в лог-файле Тестера они как соседние бары отсутствуют:

EURUSD,M1: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
EURUSD,M1: Time[1] = 2009.09.01 23:46:00
EURUSD,M1: Time[0] = 2009.09.01 23:49:00
EURUSD,M1: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

EURUSD,M1: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
EURUSD,M1: Time[1] = 2009.09.02 10:30:00
EURUSD,M1: Time[0] = 2009.09.02 10:31:00
EURUSD,M1: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@



Т.е. отсутствует случай когда Бар 10:30 следует за Баром 23:49 (что в результате приводит к проблемам в работе).
С чем это может быть связано? (похоже на баг)

Файлы:
20241214_bug.zip  1 kb
 

Правильно ли я понимаю, что спецификатор delete нет смысла использовать, если может быть использована ссылка/указатель на базовый класс? Или в таких случаях необходимо закрытое наследование? Как принято поступать?

class Base
  {
public:
   void method() { Print(__FUNCSIG__); }
  };

class Foo : public Base
  {
   void method() = delete;
  };

void OnStart()
  {
   Foo foo;
   f(foo);
  }

void f(Base &b)
  {
   b.method();
  }
 
Vladislav Boyko #:
Или в таких случаях необходимо закрытое наследование?

При закрытом наследовании тоже геморой - придется для других публичных методов что-то такое городить:

class Base
  {
public:
   void method() { Print(__FUNCSIG__); }
   void method2() { Print(__FUNCSIG__); }
  };

class Foo : private Base
  {
   void method() = delete;
public:
   void method2() { Base::method2(); }
  };

void OnStart()
  {
   Foo foo;
   foo.method2();
  }

В общем, не до конца понимаю логику использования delete в этом контексте.

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

Хотя, вероятно, я просто изначально наплужил с архитектурой.
 
При активной загрузке исторических данных, когда в таймере вызывается CopyRates (), крайне нестабильно ведёт себя iBarShift и даже iBars. Выдаётчасто-1 на тех участках, где данные уже загружены. Решается только вычислением номера бара собственными силами, когда в памяти приходится держать свой массив времени открытия баров.
Написать воспроизводящий проблему код могу, если будет запрос со стороны.  разработчиков.  Проблема очень старая, которая не решается много лет. 
Раньше решал своими функциями ( fBarShift), в которых использовалась функция iBars. Но и она теперь глючит.
 
Nikolai Semko #:
При активной загрузке исторических данных, когда в таймере вызывается CopyRates (), крайне нестабильно ведёт себя iBarShift и даже iBars. Выдаётчасто-1 на тех участках, где данные уже загружены. Решается только вычислением номера бара собственными силами, когда в памяти приходится держать свой массив времени открытия баров.
Написать воспроизводящий проблему код могу, если будет запрос со стороны.  разработчиков.  Проблема очень старая, которая не решается много лет. 
Раньше решал своими функциями ( fBarShift), в которых использовалась функция iBars. Но и она теперь глючит.

ИМХО, iBarShift не место в пятерке, как и другим iXXX. От буфферизации таймсерий отказались (которая была в четверке), но продолжаем писать, делая вид, как будто буфферизация есть.

Nikolai Semko #:
Решается только вычислением номера бара собственными силами, когда в памяти приходится держать свой массив времени открытия баров.

Единственное правильное решение, ИМХО.

 
Vladislav Boyko #:

ИМХО, iBarShift не место в пятерке, как и другим iXXX. От буфферизации таймсерий отказались (которая была в четверке), но продолжаем писать, делая вид, как будто буфферизация есть.

Единственное правильное решение, ИМХО.

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

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

1...359135923593359435953596359735983599360036013602360336043605...3768
Новый комментарий