Я портировал старый код. Это 15 лет и используется для компиляции с каким-то старым компилятором Borland. Мы не можем скомпилировать старый код из-за отсутствия зависимостей/компилятора.Чтение и запись необработанного объекта на диск (istream) через компиляторы
У нас есть что-то вроде этого:
class SegmentParameterDataRecord
{
private:
int32_t parameterId;
double value;
public:
SegmentParameterDataRecord() : parameterId(0), value(0.0) {}
int32_t & getParameterId() { return parameterId; }
double & getValue() { return value; }
void read(std::istream & in);
void write(std::ostream & out);
};
Обратите внимание на read и write методы. Вот они:
void SegmentParameterDataRecord::read(std::istream & in)
{
in.read((char *) this, sizeof(*this));
}
void SegmentParameterDataRecord::write(std::ostream & out)
{
out.write((char *) this, sizeof(*this));
}
Это вызвало у меня некоторые опасения. Обратите внимание, что старый код передает char * и обрабатывает данные как необработанные байты памяти. Я считаю, что у меня возникают проблемы, когда я переносил этот код на последнюю версию MinGW.
1) Возможно ли, что внутреннее представление память SegmentParameterDataRecord отличается по компиляторов, и, таким образом, было бы проблематично writeSegmentParameterDataRecord на одном компиляторе (15-летнего Борланд), а затем read его на другой компилятор (последние MinGW)?
2) Возможно ли, что sizeof(SegmentParameterDataRecord) может отличаться от 15-летнего компилятора Borland для сегодняшнего MinGW?
3) Насколько вероятна эта возможность?
Я бы предположил, что это был 16-разрядный компилятор, учитывая большое количество неиспользуемого пространства в структуре. Если это так, вы должны быть в состоянии спасти его __ атрибутом __ ((упакован)). Дважды проверьте, сравнив sizeof (SegmentParameterDataRecord) с старыми и новыми компиляторами. Вам нужно то же самое значение, чтобы сделать снимок при спасении данных. –
@HansPassant Что вы подразумеваете под неиспользованным пространством? – 0x499602D2
Также интересно, что означает Ганс из неиспользуемого пространства. Я могу подтвердить, однако, что двоичный файл появляется (не обязательно), чтобы заняться гораздо большим пространством для объекта, чем G ++. Это догадка, основанная на анализе двоичного кода. –