[serialization] Serializing const* to serialized data

[Noah Roberts]

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?

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Emil Dotchevski-3]

On Thu, Nov 5, 2009 at 4:08 PM, Noah Roberts <roberts.noah@...> 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
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Noah Roberts]

In article <c72e33ce0911051651le8017fes28076be7778b87f5@...>,
emildotchevski@... says...

>
> On Thu, Nov 5, 2009 at 4:08 PM, Noah Roberts <roberts.noah@...> 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.

_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Emil Dotchevski-3]

On Fri, Nov 6, 2009 at 11:00 AM, Noah Roberts <roberts.noah@...> wrote:

> In article <c72e33ce0911051651le8017fes28076be7778b87f5@...>,
> emildotchevski@... says...
>>
>> On Thu, Nov 5, 2009 at 4:08 PM, Noah Roberts <roberts.noah@...> 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
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Robert Ramey]

Noah Roberts wrote:

> In article
> <c72e33ce0911051651le8017fes28076be7778b87f5@...>,
> emildotchevski@... says...
>>
>> On Thu, Nov 5, 2009 at 4:08 PM, Noah Roberts
>> <roberts.noah@...> 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



_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Emil Dotchevski-3]

On Fri, Nov 6, 2009 at 12:36 PM, Robert Ramey <ramey@...> wrote:

> Noah Roberts wrote:
>> In article
>> <c72e33ce0911051651le8017fes28076be7778b87f5@...>,
>> emildotchevski@... says...
>>>
>>> On Thu, Nov 5, 2009 at 4:08 PM, Noah Roberts
>>> <roberts.noah@...> 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
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Robert Ramey]

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 



_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Emil Dotchevski-3]

On Fri, Nov 6, 2009 at 3:03 PM, Robert Ramey <ramey@...> 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
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Michael Caisse-2]

Emil Dotchevski wrote:

> On Fri, Nov 6, 2009 at 3:03 PM, Robert Ramey <ramey@...> 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


_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Emil Dotchevski-3]

On Fri, Nov 6, 2009 at 4:01 PM, Michael Caisse
<boost@...> wrote:

> Emil Dotchevski wrote:
>> On Fri, Nov 6, 2009 at 3:03 PM, Robert Ramey <ramey@...> 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
_______________________________________________
Boost-users mailing list
Boost-users@...
http://lists.boost.org/mailman/listinfo.cgi/boost-users