Будет ли это являться сериализацией?

Question

[sanek2005]

Объект некого класса приведением к указателю на char превращаем в биты, и записываем через поток в файл. Не это ли пресловутая сериализация?
Если что, вот код для примера:

ofstream out("lol.bin", ios::binary);

	Lol lol;

	lol.a = 129039;

	lol.b = 2012093319;

	out.write((char*)&lol, sizeof(Lol));

Answer 1

[Армянское Радио]

Это будет работать только в том случае, если все поля класса хранятся внутри него, грубо говоря, если класс не хранит в себе никаких указателей или их суррогатов (итераторов).

Если же полем вашего класса является указатель (или суррогат), вам придется рекурсивно сериализовывать уже его, что выльется в огромный рост сложности.

Comments

[Василий Банников]

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

[Армянское Радио]

Василий Банников, это уже тонкости, но вы правы - как только встанет вопрос переносимости между компиляторами / платформами, повылезают проблемы с выравниванием, размерами типов и порядком байт

[maaGames]

Если подытожить, то это можно считать сериализацией только для POD типов и с кучей оговорок об использовании.

[Евгений Шатунов]

maaGames, да, но нет. POD или тривиальные типы могут спокойно содержать указатели.

[maaGames]

Евгений Шатунов, тривиальные типы по определению не могут содержать ссылки или указатели. POD тоже. Нет конструктора копирования по умолчанию - не тривиальный. Пожалуй, только одно исключение могу придумать, если в POD структуре есть указатель, но объект им не владеет и не управляет временем жизни, тогда конструктор копирования по умолчанию можно использовать. Но я никогда не считал за POD объекты с указателями, поэтому даже как-то не подумал про это.

[Евгений Шатунов]

maaGames, а покажи документ, где явно говорится о том, что тривиальный тип не может содержать указатели.

[maaGames]

Евгений Шатунов, Вы сами мне документ скинули про "тривиальные". Там английским по белому написано, что такое тривиальный тип. Сам по себе указатель - тривиальный тип, но класс, содержащий указатель (и владещющий адресуемым объектом) не является тривиальным типом.

[Евгений Шатунов]

maaGames,

Сам по себе указатель - тривиальный тип

Да, по приведенным мной ссылкам это написано.

но класс, содержащий указатель (и владещющий адресуемым объектом) не является тривиальным типом.

Но вот этого там не написано.

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

Сейчас, согласно стандарту, я знаю что тривиальность составного типа выводится из тривиальности его конструкторов. Тривиальность конструкторов подтверждается через тривиальность типов полей рассматриваемого составного типа.
Указатель является тривиальным т.к. является скаляром, значит его наличие в составном типе разрешает типу оставаться тривиальным.
Это не дает лично мне опираться на формальную тривиальность типа при написании некоторого обобщенного кода. Поэтому если у тебя есть точная информация из стандарта или документации, которую я мог упустить, то я буду рад если ты ей поделишься.

[maaGames]

Евгений Шатунов, Я не вижу противоречий. Если объект не владеет адресуемым объектом, то он может быть тривиальным, несмотря на наличие ссылки или указателя. Если он владеет объектом, то, по определению (из данной вами ссылки), не может быть тривиальным, потому что у него будет нетривиальный конструктор копирования и деструктор (не рассматриваем вариант с утечкой памяти).

[Евгений Шатунов]

maaGames,

Если он владеет объектом, то, по определению (из данной вами ссылки), не может быть тривиальным, потому что у него будет нетривиальный конструктор копирования и деструктор (не рассматриваем вариант с утечкой памяти).

Это утверждение требует точной ссылки на цитату в стандарте.

[maaGames]

Евгений Шатунов, первая же строчка по вашей ссылке "T is TrivialType (that is, a scalar type, a trivially copyable class with a trivial default constructor". Если !"trivially copyable class", то это не TrivialType. Именно это я имел в виду под "по определению".
В любом случае, тривиальный или нет, но наличие указателя запрещает "сериализацию" бинарного дампа памяти всего объекта разом. Всё, я потерял интерес к этой теме.

[Евгений Шатунов]

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

Повторюсь что я легко могу понять твое утверждение на уровне концепций разработки, уже выше формальных правил стандарта. Однако изначально я говорил только в рамках формальных правил стандарта и просил тебя дать информацию только в рамках стандарта.
В качестве примера. Формальные правила стандарта не запрещают тебе делать битовый сдвиг вправо для целого числа, но если число будет отрицательным, стандарт формально говорит что дальнейшее поведение программы не определено. Это уже на более высоком уровне мы строим логические правила и договариваемся не сдвигать отрицательные целые, т.к. будет UB.
Разделять важно, т.к. в иной ситуации опираясь на логические правила ты можешь ошибиться в изложении формального кода и транслятор эту ошибку не обозначит.

[maaGames]

Евгений Шатунов, "и транслятор эту ошибку не обозначит. "
Именно поэтому я даже предположить не мог, что объект с указателем формально может считаться тривиальным. По вашей ссылке написано: "тривиальный конструктор копирования (и прочее тривиальное)", если конструктор не тривиальный, то весь объект более не тривиальный. Без привязки к указателям. Если объект владеет адресуемым объектом, то, в корректно реализованном объекте, будет нетривиальный конструктор копирования(присваивание) и деструктор. Исключением будет только "= delete" конструктор копирования и тривиальный деструктор с утечкой памяти. Так что я не понимаю, где вы видите формальное "разрешение" указателей в тривиальных объектах. Требование тривиального конструктора копирования делает объект с указателями (с владением) нетривиальным. По моему, это написано понятно и достаточно формализовано.

[Евгений Шатунов]

maaGames,

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

Это изложено в стандарте или это продиктовано какой-либо формой этики? Если это изложено в стандарте, то нужны цитаты с точно такой же передачей смысла.

Если объект владеет адресуемым объектом, то, в корректно реализованном объекте, согласно стандарту, адресуемый объект находится по значению, т.е. расположен в памяти своего хозяина и имеет характеристику жизни своего хозяина. Только так стандарт определяет владение.

[maaGames]

Евгений Шатунов, Адресуемый указателем объект находится по указателю вне памяти "хозяина", а не по значению и имеет время жизни до удаления в деструкторе или до падения программы (если не реализован сборщик мусора). Всё, мне надоел этот офтоп. Если вам интересно, читайте стандарт. Мне не интересно пререкаться по всяким придиркам.

[Евгений Шатунов]

maaGames, а ведь ты мог бы просто согласиться с тем, что твое изложение идет с т.з. некоторой этики разработки. Ведь именно это на самом деле и происходило. Ты оперировал на уровне некоторой смысловой надстройки над стандартом, созданной с учетом изложения стандарта. И ведь я трижды дал понять что не против этого. Для меня важно только провести границу.

Чрезмерная опека, чем и являются подобные смещения смысловых надстроек в область стандартов, всегда приводит людей к бессознательному соблюдению определенных ритуалов. Своеобразный карго-культ. В результате, конкретно в этой ситуации, слабо квалифицированный человек может прочитать твои слова и подумать что он вообще и всегда будет защищен со стороны std::is_trivial. И это будет ошибкой.

[maaGames]

Евгений Шатунов, По вашей ссылке написано, тип тривиальный, если А(скаляр) и Б(тривиальный коснтруктор копирования). Б не выполняется, значит - не тривиальный. Мне не с чем соглашаться.
В первом же сообщении я написал "и с кучей оговорок об использовании". Понимание происходящег и, что воообще там программируешь попадает под "оговорки".

[Евгений Шатунов]

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

[maaGames]

Евгений Шатунов, Повторяю. А - содержит только тривиальные типы, Б - имеет тривиальный конструктор копирования. В вашем примере тривиальный конструктор копирования, поэтому А и Б выполняется. Напиши конструктор копирования и сработает ассерт.
Оговорка - не из стандарта. Сама оговорка: если объект не владеет адресуемым объектом, то он может быть тривиальным. т.е. допускает побайтовое копирование указателя без нарушения инварианта. Это настолько очевидные вещи, что я не понимаю, о чём мы говорим. Иначе класс прсто неправильно реализован. Правильную и неправильную реализацию формализовать нельзя (без явной аттрибуции), потмоу что и тот и тот код может быть верным в зависимости от "оговорок".
А и Б сложите вообще через & из той ссылки, которую вы дали. Сами пишите неправильныи пример, проверяющий не то, о чём мы говорим и используете это в качестве доказательной базы...
Вообще, я очень надеюсь, что в стандарте это помечено как UB.

[maaGames]

Евгений Шатунов, Ещё раз повторю, чтобы вы точно поняли. Тривиальный конструктор копирования создаётся компилятором. Если вы сами его пишите, то это нетривиальный конструктор и объект перестаёт быть тривиальным. И ваш пример ассертит тогда.

[Евгений Шатунов]

maaGames,

Оговорка - не из стандарта. ... Правильную и неправильную реализацию формализовать нельзя (без явной аттрибуции), потмоу что и тот и тот код может быть верным в зависимости от "оговорок".

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

Мне не с чем соглашаться.

Я все правильно понял?

Вообще, я очень надеюсь, что в стандарте это помечено как UB.

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

[maaGames]

Евгений Шатунов, Нет. В стандарте указано А и Б. Если А и Б выполняется, то тривиальный. Если не выполняется, то не тривиальный. Оговорка в том, что выполнение А и Б не гарантирует, что тип тривиальный, хотя в приведённой ВАМИ ссылке указано, что у тривиального типа выполняется А и Б. Т.е. А и Б это необходимое, но не достаточное условие. Достаточность в стандарте не указана, потому что определяется логикой программы. Фактически, по стандарту, вообще не может существовать тривиального типа, содержащего указатель, потому что невозможно доказать его тривиальность, не имея всего кода приложения. Один и тот же класс может быть тривиальным и не тривиальным в зависимости от использующего класс кода.