[serialization] Serializing const* to serialized data
Consider something like so: struct A { ...? }; struct B { std::list<A> items; }; struct C { A const* ptr_to_item_in_B_items; }; Serializing B is easy. Serialization of C ... not so much. The naive approach did not work because it wants a non-const pointer. Having read posts about the problem it seems the serialization library expects to modify the data pointed to, but I don't need or want that...I just want to recover the structure layout. Possible? Impossible?
On Thu, Nov 5, 2009 at 4:08 PM, Noah Roberts <roberts.noah@gmail.com> wrote:
Consider something like so:
struct A { ...? };
struct B { std::list<A> items; };
struct C { A const* ptr_to_item_in_B_items; };
Possible? Impossible?
Could you explain the semantics you intend for serializing ptr_to_item_in_B_items? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
In article <c72e33ce0911051651le8017fes28076be7778b87f5@mail.gmail.com>, emildotchevski@gmail.com says...
On Thu, Nov 5, 2009 at 4:08 PM, Noah Roberts <roberts.noah@gmail.com> wrote:
Consider something like so:
struct A { ...? };
struct B { std::list<A> items; };
struct C { A const* ptr_to_item_in_B_items; };
Possible? Impossible?
Could you explain the semantics you intend for serializing ptr_to_item_in_B_items?
I want to recover the structure layout. If a C had a pointer to A item X in C then when it reloads it should point at X again.
On Fri, Nov 6, 2009 at 11:00 AM, Noah Roberts <roberts.noah@gmail.com> wrote:
In article <c72e33ce0911051651le8017fes28076be7778b87f5@mail.gmail.com>, emildotchevski@gmail.com says...
On Thu, Nov 5, 2009 at 4:08 PM, Noah Roberts <roberts.noah@gmail.com> wrote:
Consider something like so:
struct A { ...? };
struct B { std::list<A> items; };
struct C { A const* ptr_to_item_in_B_items; };
I want to recover the structure layout. If a C had a pointer to A item X in C then when it reloads it should point at X again.
Sure but what do you imagine in terms of a serialization library? Obviously, *you* could serialize your pointer, for example as index in the list, but all that the serialization library sees is a pointer. It has no way of knowing that it points an element within the list, it has no way of knowing that there is a list even. But maybe I'm missing something so I asked how would that work. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Noah Roberts wrote:
In article <c72e33ce0911051651le8017fes28076be7778b87f5@mail.gmail.com>, emildotchevski@gmail.com says...
On Thu, Nov 5, 2009 at 4:08 PM, Noah Roberts <roberts.noah@gmail.com> wrote:
Consider something like so:
struct A { ...? };
struct B { std::list<A> items; };
struct C { A const* ptr_to_item_in_B_items; };
Possible? Impossible?
With the possible exception of the "const" this should work fine. In fact, the main demo included with the package and described in the tutorial does exactly this. For this to work, struct B would have to be serialized before struct C. If this is not done, one will get an exception since otherwise would endup with two copies of the original A. Assuming we avoid this trap, the tracking facility addresses this. As list<A> is saved, the addresses of all the A elements are saved. When (later) C is saved, only a reference to the original copy is saved. On loading its the same processess in reverse. All this happens without the programmer/user needing to do anything special other than make sure that the types are not "untracked". In almost all cases, the defaults will give the behavior desired without the programmer/user even being aware of it. Robert Ramey
On Fri, Nov 6, 2009 at 12:36 PM, Robert Ramey <ramey@rrsd.com> wrote:
Noah Roberts wrote:
In article <c72e33ce0911051651le8017fes28076be7778b87f5@mail.gmail.com>, emildotchevski@gmail.com says...
On Thu, Nov 5, 2009 at 4:08 PM, Noah Roberts <roberts.noah@gmail.com> wrote:
Consider something like so:
struct A { ...? };
struct B { std::list<A> items; };
struct C { A const* ptr_to_item_in_B_items; };
All this happens without the programmer/user needing to do anything special other than make sure that the types are not "untracked". In almost all cases, the defaults will give the behavior desired without the programmer/user even being aware of it.
Interesting. Then why won't it work with A const *? If I understand correctly, there are two possibilities for serializing a A const * pointer: 1) This address has been "seen" before. In this case, you don't serialize the pointee, and whether or not it is const is irrelevant. 2) The address hasn't been "seen" before, so you new an object of type A, serialize that, then set the (const) pointer being serialized to A. Either way, why does it matter if we're dealing with a pointer-to-const? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
Either way, why does it matter if we're dealing with a pointer-to-const?
It doesn't. The error/warning or whatever for using a "const" is unrelated to this. It's being considered what it means to load a pointer to a const object and whether or not this should be trapped. This is the subject of a Track Item. Robert Ramey.
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Fri, Nov 6, 2009 at 3:03 PM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
Either way, why does it matter if we're dealing with a pointer-to-const? It doesn't.
The error/warning or whatever for using a "const" is unrelated to this. It's being considered what it means to load a pointer to a const object and whether or not this should be trapped. This is the subject of a Track Item.
This is not a pointer to a const object. It is a const pointer to a mutable object. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Fri, Nov 6, 2009 at 3:03 PM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
Either way, why does it matter if we're dealing with a pointer-to-const?
It doesn't.
The error/warning or whatever for using a "const" is unrelated to this. It's being considered what it means to load a pointer to a const object and whether or not this should be trapped. This is the subject of a Track Item.
This is not a pointer to a const object. It is a const pointer to a mutable object.
A const* ptr_to_item_in_B_items; is a pointer to a constant (immutable) A A * const ptr_to_item_in_B_items; is a constant pointer to a mutable A object The example has the former. Or did I miss something? michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
On Fri, Nov 6, 2009 at 4:01 PM, Michael Caisse <boost@objectmodelingdesigns.com> wrote:
Emil Dotchevski wrote:
On Fri, Nov 6, 2009 at 3:03 PM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
Either way, why does it matter if we're dealing with a pointer-to-const? It doesn't.
The error/warning or whatever for using a "const" is unrelated to this. It's being considered what it means to load a pointer to a const object and whether or not this should be trapped. This is the subject of a Track Item.
This is not a pointer to a const object. It is a const pointer to a mutable object.
A const* ptr_to_item_in_B_items;
is a pointer to a constant (immutable) A
I wrote it wrong in my previous post and it confused you, I meant to say that we have a pointer-to-const that points a mutable object. In other words, you can't modify the object through that pointer but when the pointer is serialized there is no need to modify the object through the pointer because in all cases the serialization library has another pointer to the same object. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
participants (1)
-
Emil Dotchevski -
Michael Caisse -
Noah Roberts -
Robert Ramey