[РЕШЕНО] Редактирование файла с помощью QDataStream

[__Heaven__]

В мире может и есть, но одобрять желание начинающего копаться seek'ом для перезаписи файла - это просто неграмотно. Самая настоящая "ерунда"  

Ерунда - перезаписывать файл в 200 Гб, когда вам нужно только поправить первые 2-3 байта

[Bepec]

Поддерживаю __Heaven__, недоумеваю от Igors.

А seek'ом пользуются все, в том числе и драйверы СУБД

[Igors]

В упор не вижу связи между задачей автора и СУБД.
Как вы запишите в СУБД то, что я запишу в файл в виде структуры:

Строка длинной 30
Количество флоатов
массив флоатов
Количество интов
Массив интов
?

По мне так, для такой простой задачи тянуть в проект СУБД = боль. Особенно, если я не знаком с SQL

А что Вы сможете здесь "редактировать" если изменилось кол-во флотов и/или интов? Будете делать ветку которая будет писать "когда кол-во не изменилось", потом отслеживать "а изменилось ли" - причем весь файл все равно писать придется.

..перезаписывать файл в 200 Гб, когда вам нужно только поправить первые 2-3 байта

А тут Вы просто не сможете загрузить его весь в память, придется что-то придумывать - и в первую очередь вспоминать о том же СУБД.

Ерунда

Еще раз - и на Ваши посты отвечать перестану

[__Heaven__]

А что Вы сможете здесь "редактировать" если изменилось кол-во флотов и/или интов? Будете делать ветку которая будет писать "когда кол-во не изменилось", потом отслеживать "а изменилось ли" - причем весь файл все равно писать придется.

В самом начале я сохранил объект m_strComment, далее уже остальные объекты.

Вопрос: как можно в следующий раз открыть файл для редактирования, чтобы изменить лишь эту переменную  m_strComment, а остальные не трогать. При этом используя класс QDataStream?

А тут Вы просто не сможете загрузить его весь в память, придется что-то придумывать - и в первую очередь вспоминать о том же СУБД.

Нет необходимости загружать его весь в память

[Old]

Еще раз - и на Ваши посты отвечать перестану

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

[Yegor]

Вижу, что это простое решение, пользоваться seek-ом. Но вот меня мучает вопрос. Во всех ли случаях, когда объект QString имеет фиксированное количество символов, он имеет всегда одинаковый фактический размер в байтах (sizeof(m_strCommnet))?
То есть его размер не зависит от языка ввода, например?

[gil9red]

Вижу, что это простое решение, пользоваться seek-ом. Но вот меня мучает вопрос. Во всех ли случаях, когда объект QString имеет фиксированное количество символов, он имеет всегда одинаковый фактический размер в байтах (sizeof(m_strCommnet))?
То есть его размер не зависит от языка ввода, например?

Все символы всегда имеют одинаковый размер

[__Heaven__]

QString stores a string of 16-bit QChars, where each QChar corresponds one Unicode 4.0 character

[Smogg]

При недостатке - забивать хвост строки "невозможными символами"

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

Ну, в общем да, никак не обойтись без явного выделения места под "коммент"... Т.е. в пустой файл надо сначала записать блок нулей, где потом будет писаться коммент. И не забывать, что нужно делать seek() перед каждым чтением/записью в зависимости от вида данных.

[Igors]

В самом начале я сохранил объект m_strComment, далее уже остальные объекты.

Вопрос: как можно в следующий раз открыть файл для редактирования, чтобы изменить лишь эту переменную  m_strComment, а остальные не трогать. При этом используя класс QDataStream?

Даже в этом простейшем случае забот хватает. QDataStream запишет свою (текущую) версию которая может не соответствовать записанным данным. Можно конечно зарезервировать фиксированное число байт в начале, сначала писать их через QFile::write, а затем уже заряжать QDataStream. Но тогда начинается возня с toLocal8bit. Да и вообще как-то коряво - чего менять комментарии если начинка старая ?

[__Heaven__]

QDataStream запишет свою (текущую) версию которая может не соответствовать записанным данным.

Мне казалось, что версию должен писать не Qt.

Код

C++ (Qt)
#include <QCoreApplication>
#include <QDataStream>
#include <QFile>
 
int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);
 
    QFile file("D:\\tmp\\bin");
    file.open(QFile::WriteOnly);
    QDataStream out(&file);
    out.setByteOrder(QDataStream::LittleEndian);
    out << QString("text");
 
    out << 1 << 2 << 3;
    return 0;
}
 

Надеюсь, картинка ниже понятная

[__Heaven__]

Кстати, пока делал пример, заинтересовало:
Почему разработчики Qt выбрали значение по умолчанию  QDataStream::BigEndian ?
Мне казалось, что Little более популярная за счёт x86

[Old]

Кстати, пока делал пример, заинтересовало:
Почему разработчики Qt выбрали значение по умолчанию  QDataStream::BigEndian ?
Мне казалось, что Little более популярная за счёт x86

Думаю, потому, что это сетевой порядок байт.

[__Heaven__]

А в каких ситуациях играет роль enum Version?

[Igors]

Мне казалось, что версию должен писать не Qt.

Правильно казалось, версию Qt он пишет для структур (напр QFont). А QString просто счетчик и по два байта на символ в юникоде.

Кстати, пока делал пример, заинтересовало:
Почему разработчики Qt выбрали значение по умолчанию  QDataStream::BigEndian ?
Мне казалось, что Little более популярная за счёт x86

Дань традиции, данные на диске в big