Ternick, вот такой прототип у фукнции: ostream& write (const char* s, streamsize n);
причём s это не строка, а любой массив байт, длиной n. Просто приводишь тип указателя на структуру к указателю на строку и записываешь. Так же делаешь при чтении.
Но делать так возможно только для POD структур, т.е. чтобы небыло никаких выделений памяти, указателей и подобного.
ubf.write( (const char*)&fstr, sizeof(fstr) );
Но так можно делать только для POD типов и лучше "дамп памяти" не сохранять. В конкретно этом случае проблемы будут только если изменится выравнивание полей структуры и байты сдвинутся, тогда может оказаться, что сохранено одно число байт, а структура уже занимает больше байт.
toster_bodnar, ну тут скорее вопрос, почему Container не шаблонный класс? Из контейнера надо получать Base и из Base уже получать USED_TYPE. А Base получать или по индексу, еслитам есть индексируемый список типов, либо прям полностью указывать тип.
Александр Ананьев, Да это понятно, но там нужно делать релизацию на WinAPI с сообщениями очереди сообщений Windows. Это выглядит костылями. Я был уверен, что Qt даёт это сделать своими средствами, без платформенно-зависимых костылей.
toster_bodnar, Добавлять указатель на объект, вместо объекта. "M* m" вместо "M m". Можно создавать указатели на неопределённый тип. При этом определение и реализация классов должна быть в разных файлах.
impelix, чтобы добавить в очередь пару чисел, это должна быть очередь пар.
std::queue<int> q1; // сюда пару вставить нельзя
std::queue< std::pair<int,int> > q2; // сюда можно только пару вставить
q1.empace( 1 );
q2.emplace( 2, 3 );
MuffinLover, while(rawWavFile) и while( !rawWavFile.fail() ) - одно и то же и было правильно. Правильнее, чем rawWavFile.eof(). значит seekg в конце цикла передвигал не в eof положение и следующая итерация запускалась, но считать уже ничего не получалось и chunk оставался старый, а на следующей итерации уже fail срабатывал.
MuffinLover, ну после eof не стоит ничего читать из файла. А после двух eof - тем более!
Не знаю, UB или не UB, скорее всего, чтение файла после eof не происходит и в chunk остаётся "мусор" с прошлого раза. Я бы ожидал, что исключеие кинет, но, не кидает, как видим.
В начале цикла while проверяй, что не eof. Вообще перед каждым чтением проdеряй, что не eof.
MuffinLover, после "if( chunk.chunkId == CT_fmt )" ты ничего не записываешь в chunk, но ожидаешь, что тип поменялся. Видимо вместо fmtChunk должен быть chunk
Urilobus, перед массивом записано, сколько байт удалять.
Можно боле ерадикально поступить и заменить массивы на std::vector. На скорости не отразится, а вручную удалять не придётся ничего. Наверняка ошибка глупая и очевидная, но я не вижу.
Urilobus, ну очевидно, что строки уже были удалены и "отрабатывает до конца" отображая мусор из памяти, который пока никто не успел перезаписать.
Для эксперимента, перед удалением векторов заполняй их числом -1, например, и у тебя окажется, что после копирования в объекте неправильные данные будут. И в отладчике отслеживай, в какой момент в скопированной матрице начинают пордтиться данные.
Выглядит так, что не обнулил указатель после копирования, но вроде всё ты обнуляешь. Визуально не вижу ошибки, так что в отладчике смотри.
Кроме вот этого места другие ошибки в глаза не бросаются
if( Mat_1 != nullptr )
{
for (int i = 0; i < rows_num; i++)
delete[] Mat_1[i];
}
ostream& write (const char* s, streamsize n);причём s это не строка, а любой массив байт, длиной n. Просто приводишь тип указателя на структуру к указателю на строку и записываешь. Так же делаешь при чтении.
Но делать так возможно только для POD структур, т.е. чтобы небыло никаких выделений памяти, указателей и подобного.