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

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

Ранее сталкивалась с тем, что появление такого окошка в процессе установки могло быть связано с защитой на компе (видимо, в связи с её каким-либо очередным обновлением) и последующим вот таким вот своеобразным проявлением.

При этом не играло роли, ранее или только что скачанный установочный файл.

Теперь возьму себе на заметку, на будущее, на всякий случай, эту новую для меня зависимость (сейчас экспериментировать не стала).

Но рада, что у вас проблема решилась.

Как предположение: Насколько помню, недавно было обновление терминала МТ5. Может, в данном случае, и есть какая-то взаимосвязь между появлением окошка с требованием ввести прокси данные, устаревшей версией установочного файла и процессом on-line установки.
 

 Из списка изменений к новому билду MT5 от 2014.04.04 10:14: "3. Terminal: Исправлена ошибка, в некоторых условиях приводившая к тому, что графические объекты не отрисовывались на графике." Вот уж не знаю, удовлетворили ли разработчики мою заявку в СД #966979 или это иного рода исправление, а то и вовсе побочный эффект от какого-то улучшения в очередном билде, но в любом случае теперь меня всё устраивает. В списке изменений сказано, что это была ошибка, но в переписке в СД мне недвусмысленно ответили: "Это не ошибка, а ограничение для экономии ресурсов."

 Теперь можно комфортно смотреть ТА-построения на любых ТФ, как и прежде.

 Благодарю, заявку закрываю. 

 

В производном классе можно переопределить константность метода (build 917)

class A {
public:
        virtual void f() const {}
        int x;
};
class B : public A {
public:
        virtual void f() /*не const*/ { x = 2; }
};
void g( const A* a ) { a.f(); }
void OnStart()
{
        A *a = new B();
        a.x = 1;
	Print( a.x ); //результат = 1
        g( a );
        Print( a.x ); //результат = 2, а обещали, что g( const A* ) не может менять объект
        delete( a );
}

Еще один пример

class A {
public:
        virtual void f() const { Print( "1" ); }
};
class B : public A {
public:
        virtual void f()       { Print( "2" ); }
};
void g( const A* a ) { a.f(); }
void OnStart()
{
        A *a = new B();
        g( a );
        delete( a );
}

Результат= 2, а в С++ результат = 1

Ошибка не в том, что в производном классе можно объявить не const метод с таким же именем как в базовом (что допустимо), а в том, что С++ считает их разными, а MQL - считает что B::f() переопределяет A::f() const

 

Функция Print() выводит float сигнальные не-числа как не-сигнальные, что нелогично, потому как double - выводятся нормально и те и другие.

У float нужно либо: 1) префикс Q у несигнальных убрать и тогда сигнальные и несигнальные будут выводится одинако, или 2) выводить сигнальные с префиксом S. Если я ошибаюсь - приведите пожалуйста пример сигнального float не-числа, которое выводилось бы  функцией Print() без префикса Q

Для примера беру заведомо сигнальное double не-число, привожу его к float и вывожу оба через Print(). В 1-ом случае печатается SNAN, во втором QNAN

 

Тут в процессе ковыряния способов записи данных в файл из тестера вот какая ошибка попалась (сокращено, т.к. не влезало):

2014.04.08 01:47:30.531 2013.07.01 02:10:00   00: 0x000000013FD1F038
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013FD1F04D 498BCD            mov        rcx, r13
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013FD1F04A 41B001            mov        r8b, 0x1
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013FD1F043 80BD3804000000    cmp        byte [rbp+0x438], 0x0
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013FD1F040 83C202            add        edx, 0x2
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013FD1F03D 418BD4            mov        edx, r12d
2014.04.08 01:47:30.531 2013.07.01 02:10:00   
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013FD1F03B EB03              jmp        0x13fd1f040
2014.04.08 01:47:30.531 2013.07.01 02:10:00      crash -->  000000013FD1F038 8B50FC            mov        edx, [rax-0x4]
2014.04.08 01:47:30.531 2013.07.01 02:10:00   
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013FD1F033 4885C0            test       rax, rax
[cut]
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013FD1EE6E 55                push       rbp
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013FD1EE67 4C894018          mov        [rax+0x18], r8
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013FD1EE63 48895808          mov        [rax+0x8], rbx
2014.04.08 01:47:30.531 2013.07.01 02:10:00                 000000013FD1EE60 488BC4            mov        rax, rsp
2014.04.08 01:47:30.531 2013.07.01 02:10:00   Access violation at 0x000000013FD1F038 read to 0x00000003FFFFFFFF

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

 
Lone_Irbis:

Тут в процессе ковыряния способов записи данных в файл из тестера вот какая ошибка попалась (сокращено, т.к. не влезало):

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

Да, опишите, пожалуйста, более подробно.

Интересует билд, ОС, битность, настройки тестера. Приложите код для воспроизведения. 

Спасибо.

 

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

Билд: MetaTester 5 x64 build 910 (07 Mar 2014) https://dl.dropboxusercontent.com/u/61587787/bugreport/build.png

Ось Win7 x64 https://dl.dropboxusercontent.com/u/61587787/bugreport/system.png

копипаст из окна тестера: https://dl.dropboxusercontent.com/u/61587787/bugreport/log.txt

скриншоты из тестера (ну, мало ли): https://dl.dropboxusercontent.com/u/61587787/bugreport/tester1.png https://dl.dropboxusercontent.com/u/61587787/bugreport/tester2.png

настройки тестера (не знаю, правильно ли понимаю, что имелось в виду): https://dl.dropboxusercontent.com/u/61587787/bugreport/config.png

Выжимка из кода: 

   int idx = 133;
   WriteCSV("test.csv",idx);
   
class Core { 
public:  
   void     WriteCSV(string FileName, string s1, string s2, string s3, string s4, string s5, string s6);
};

void Core::WriteCSV(string FileName, string s1, string s2="", string s3="", string s4="", string s5="", string s6=""){
   int handle = FileOpen(FileName,FILE_CSV|FILE_WRITE|FILE_SHARE_WRITE|FILE_UNICODE|FILE_COMMON,"~");
   if(handle == INVALID_HANDLE) Print("error");
   else FileWrite(handle,s1,s2,s3,s4,s5,s6);
   FileClose(handle);
}

Если заменить на WriteCSV("test.csv",(string)idx); - ошибка исчезает. Другие не-строковые переменные тут ничего не дают. Хотя не похоже, чтобы была разница, чему именно равняется idx (это просто порядковый номер новости в массиве). Воспроизводится на любой новости при попытке сохранения результата. Из предупреждений выводится только implicit conversion from 'number' to 'string', но опять же только в этом случае он оборачивается крэшем.

Сюда выкладывать код целиком и .set к нему как-то не хотелось бы, но могу куда-нибудь прислать. 

1...111111121113111411151116111711181119112011211122112311241125...3519
Новый комментарий
Причина обращения: