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

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

Нет. FileFlush надо делать обязательно, если хотите, чтобы кто-то ещё смог прочитать изменённый файл

Проблема в том, что MQL5 программа при открытии читает файл в собственный буфер. И ничего не узнает о том, что в файле что-то изменилось, пока снова не прочитает файл. Снова прочитать файл можно только при закрытии и последующем открытии этого файла

Слава, это проблема именно. Пожалуйста, посмотрите на ссылку, которую я публикую выше, вы найдете код для его воспроизведения.

Тот же файл открывается из одного советника, 1 дескриптор для записи, 2-й для чтения, fileflush используется после записи, попробуйте прочитать, и это не работает правильно.

Конечно, если вы закрываете / открываете, это работает, но тогда нет необходимости использовать FileFlush.

 
Alain Verleyen:

Слава, это проблема именно. Пожалуйста, посмотрите на ссылку, которую я публикую выше, вы найдете код для его воспроизведения.

Тот же файл открывается из одного советника, 1 дескриптор для записи, 2-й для чтения, fileflush используется после записи, попробуйте прочитать, и это не работает правильно.

Конечно, если вы закрываете / открываете, это работает, но тогда нет необходимости использовать FileFlush.

Я понимаю описанную Вами проблему.

1-й советник пишет файл. Он может не закрывать этот файл, но в таком случае должен вызывать FileFlush

2-й советник читает файл. Он должен каждый раз открывать файл, потом закрывать.

Открытие и закрытие файла только для второго советника!

 
Slava:

Я как раз об этом и говорю. Закрыть, потом снова открыть

Или Вы имеете в виду FileFlush перед закрытием файла?

Да, нужно ли флашить перед закрытием? Или закрытие гарантирует актуальность записанного файла.

 
Andrey Barinov :

Да, нужно ли флашить перед закрытием? Или закрытие гарантирует актуальность записанного файла.

Промывка бесполезна, если вы закрываете сразу после.
 
Slava :

Я понимаю описанную Вами проблему.

1-й советник пишет файл. Он может не закрывать этот файл, но в таком случае должен вызывать FileFlush

2-й советник читает файл. Он должен каждый раз открывать файл, потом закрывать.

Открытие и закрытие файла только для второго советника!

Я понимаю, что это обходной путь.

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

 
Andrey Barinov:

Да, нужно ли флашить перед закрытием? Или закрытие гарантирует актуальность записанного файла.

Не обязательно. Буфера сбрасываются автоматически, если перед закрытием не было вызова FileFlush

 

Баг МТ5 (build 2390) некорректный подсчет фигурных скобок в описании структуры класса. 

class A{};
class B : public A; };  // Ok

class C : public A;    

void OnStart()
{
   A a;
}                      // Compile Error: '}' - unexpected end of program        
 
Slava:

Эксперт, который читает файл, должен держать этот файл закрытым.

Особенность реализации файлов в MQL5 такова, что они по максимуму держат данные из файлов в собственных буферах. Если объём информации настолько велик, что не помещается в буфер, тогда Ваш трюк с перестановкой указателя в начало потом в конец файла может сработать.

Поэтому на данный момент открывайте файл, проверяйте содержимое, потом снова закрывайте

Как я сообщал выше (в тексте, который вами же отквочен), конкретно в моем тест-кейсе все наоборот -- читает индикатор, пишет эксперт. Но насколько я понял, тип программы не важен. Проблема архитектурная.

Указанная реализация файлов в MQL5 -- это баг. Закрывать и открывать файл -- рабочий обходной маневр, но так не должно быть для чтения разделяемого файла.

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

PS. В качестве quick&dirty исправления такое предложение: в ответ на вызов FileFlush у файла открытого на чтение - обновлять его буфер.

 
Vict:

Наверное потому, что мкл с++ подобный, а туда структуры из си пришли.

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

Так ведь в C++ структуры и классы - это одно и то же.   Поэтому все ваши рассуждения о "выразительности кода" не влияют на суть вещей. Вы с таким же успехом можете через дефайн определить любое другое выразительное для вас слово, помимо struct или class, и это ничего не изменит (я про C++)

Поэтому рассуждать о структурах следует лишь с точки зрения C#.  Именно оттуда взята их концепция.  Структуры - это value-типы, поэтому они гораздо компактней, чем классы, не полиморфны, и на них нельзя брать ссылку.  Вот последнее - особенно важно.
 

Никакого зла там нет, вам кажется. Вон в стандарт протянули даже: чтение неинициализированного unsigned char и std::byte не undefinded behavior. Можно агрегатную инициализацию для POD. И не забывайте - вся эта инициализация не бесплатна, эта реальные расходы ресурсов (цпу, память, размер экзешника). Если вам класть на это со своей числодробилкой, то в случае какого-нибудь микроконтроллера это может быть важно. Ведь С/С++ это не только виндовое формошлёпство вроде шарпа.

Одна лишь инициализация одной переменной увеличила размер инструкций на 30%. 

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

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

int a= 0;  // Эту инициализацию компилятор вырежет
//...
a= 10;

Можете хоть 100 раз подряд их инициализировать.  Поэтому вся эта паранойя насчёт боязни предварительной инициализации переменных просто нелепа.  На дворе 2020 год.  Тем более если вы ведёте речь о POD-структурах.  Уж их инициализацию компилятор точно оптимизирует на раз-два.

Отсутствие предварительной инициализации допустимо лишь тогда, когда есть 100% контроль компилятора, запрещающий чтение неинициализированных переменных.

 
Alexey Navoykov:

Так ведь в C++ структуры и классы - это одно и то же.   Поэтому все ваши рассуждения о "выразительности кода" не влияют на суть вещей. Вы с таким же успехом можете через дефайн определить любое другое выразительное для вас слово, помимо struct или class, и это ничего не изменит (я про C++)

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

Поэтому рассуждать о структурах следует лишь с точки зрения C#.  Именно оттуда взята их концепция.  Структуры - это value-типы, поэтому они гораздо компактней, чем классы, не полиморфны, и на них нельзя брать ссылку.  Вот последнее - особенно важно.

Вы думаете что ваш шарп появился в чистом поле? Корни в Си, структура - это тупо контейнер без лишнего сахара.

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

int a= 0;  // Эту инициализацию компилятор вырежет
//...
a= 10;

Можете хоть 100 раз подряд их инициализировать.  Поэтому вся эта паранойя насчёт боязни предварительной инициализации переменных просто нелепа.  На дворе 2020 год.  Тем более если вы ведёте речь о POD-структурах.  Уж их инициализацию компилятор точно оптимизирует на раз-два.

Да откуда такая уверенность? Вызов функции из другой единицы трансляции/другого модуля/циклы/компилятор не в духе/... . Не переоценивайте возможности оптимизатора. Это не Copy elision оптимизация, которую обязали делать компиляторы. Если оптимизаторы станут столь умны и это перестанет что-то стоить, то в очередно Cи стандарте пропишут: "дефолтная инициализации не оставляет объект в неопределённом состояни".
1...271727182719272027212722272327242725272627272728272927302731...3519
Новый комментарий
Причина обращения: