Ну, раз уж такое дело пошло и нас учат корректно запрещать создавать объекты в стеке, я тоже свои пять копеек оставлю.
Итак, есть класс A:
[c++]
struct A: virtual some_base_class, some_other_class {
virtual f();
};
[/c++]
При записи берем и пишем объект этого класса целиком в поток:
[c++]
A *a = new A();
...
stream.write((const char *) a, sizeof(A));
[/c++]
Теперь, внимание, самое интересное.
Теперь мы читаем класс из потока, пусть нам извсетно что этот класс -- A. Сначала мы заводим буффер, считываем туда блок памяти, а потом конструируем класс в этом буфере с помощью placement new.
sch>Ну, раз уж такое дело пошло и нас учат корректно запрещать создавать объекты в стеке, я тоже свои пять копеек оставлю.
sch>Теперь, внимание, самое интересное. sch>Теперь мы читаем класс из потока, пусть нам извсетно что этот класс -- A. Сначала мы заводим буффер, считываем туда блок памяти, а потом конструируем класс в этом буфере с помощью placement new.
sch>[c++] sch>char *buf = malloc(sizeof(A)); sch>stream.read(buf, sizeof(A)); sch>new (buf) A(); sch>[/c++]
sch>В результате мы получаем все pod-данные A загруженными, да и структура A тоже восстановлена! По-моему здорово.
sch>[c++] sch>struct some_strange_object {};
sch>struct A { sch> int var;
sch> A() { sch> var = 0; sch> }
sch> A(some_strange_object *p) { sch> } sch>};
sch>P.P.S. Ну, а не-POD типы нужно будет грузить вручную, пользуясь другими методиками.
Чем это лучше std::copy или memcpy? Еще одиним бесполезным конструктором?
Здравствуйте, Pavel Chikulaev, Вы писали:
sch>>P.P.S. Ну, а не-POD типы нужно будет грузить вручную, пользуясь другими методиками.
Здесь конечно же имелись в виду не-POD члены классов.
PC>Чем это лучше std::copy или memcpy? Еще одиним бесполезным конструктором?
У нас например много классов с большим количеством этих самых POD-членов. Используя эту методику мы значительно уменьшили количество элементов в таблице сериализации. Недостаток основной заключается в том, что очень трудно найти неинициализированный указатель после десериализации.
sch>Ну, раз уж такое дело пошло и нас учат корректно запрещать создавать объекты в стеке, я тоже свои пять копеек оставлю.
sch>Итак, есть класс A: sch>[c++] sch>struct A: virtual some_base_class, some_other_class { sch> virtual f(); sch>}; sch>[/c++]
[c++][/c++] — это что новые коды форматирования С++?
Так не устраивает:
Здравствуйте, Pavel Chikulaev, Вы писали:
sch>>P.P.S. Ну, а не-POD типы нужно будет грузить вручную, пользуясь другими методиками.
PC>Чем это лучше std::copy или memcpy? Еще одиним бесполезным конструктором?
memcpy перезапишет полезные члены данных.
А нам нужно только записать указатель на таблицу виртуальных фукнций и таблицу смещений виртуальных баз.
PC>Сорри конечно, но по-моему это sux
Это стандартная и общеизвестная методика загрузки данных на игровых консолях, на которых очень мало оперативной памяти и жёсткие требования ко времени загрузки игры.
Там не скажешь, "ну укажем в системных требованиях на 512 мб. оперативной памяти больше."
Целый уровень может быть загружен одним куском памяти.
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, sch, Вы писали:
S>Вопросы выравнивания, и платформенных архитектур автором, как я понял оставленны в стороне, Биг/Литле Эндианы — просто отдыхают
S>Все элегантно, и просто
У себя я использовал ptrdiff_t.
Код, очевидно, непереносимый ни в том, ни в другом случае.
Но ptrdiff_t явным образом знаковый, плюс не нужно преобразование типа (size_t)in_p.
В общем, работает или не работает и то и другое, но ИМХО ptrdiff_t здесь чище и нагляднее.
Здравствуйте, _Winnie, Вы писали:
_W>Целый уровень может быть загружен одним куском памяти.
А зачем ему быть таким сложным? Может просто POD сделать да и всё?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском