Re: [boost] [serialization] Regressions?

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-06-23 23:03:12

>Each check is only reasonable if it finds more bugs than it causes
>problems. We seem to disagree about the proportion for the *specific case*
of the >check in serialization library.

I guess so. But you might check Joaquin's previous message regarding this.

>> Of course your correct on this.  But lot's of people drive without
>> seat belts too.  That doesn't mean that the rest of us should be
>> prohibited from using them.

>I don't think the analogy is correct. I guess if you were required to
>refasten the belt each time you change gear, you won't be using it.

If this is happening more than an occasionally, I would guess you're using
the library in ways that I failed to envision.  In my demos and examples it
was easy to avoid the problem without casts and the tests/demos do things
like save and load within the same function that not the most usual case.

>> Default trait is non-primitive objects is "track_selectivly"  This
>> means that objects will be tracked if and only anywhere in the
>> source, some object of this class is serialized through a pointer.
>> So when I'm compiling one module above and checking at compile time I
>> realy don't know that the object will in fact be tracked. So I trap
>> unless the serialization trait is set to "track never".  To
>> reiterate, in this case the object won't be tracked unless somewhere else
its serialized as a pointer.

>I'm not sure this behaviour is right. It certainly matters if I save
>the
>*same* object as pointer or not. Why does it matter if I have *another*
>object by  pointer.

>Suppose you've saving an object with the same address twice. There
>possible situations are:

>1. Both saves are via pointers. You enable tracking for this address;
>only one object is actually saved. User is responsible for making sure
>that the object does not change between saves.

>2. First save is via pointer, the second is not by pointer. You throw
>pointer_conflict.

>3. First save is not by pointer, second is by pointer. You ehable
>tracking >for this address.

>4. Both saves are not via pointer. You don't track anything.

>Is there anything wrong with above behaviour?

#3 -for this address-. We can't know at compile time what the addresses of
the objects are.  If an object of a certain type is serialized anywhere in
the program through a pointer, we have to instantiate code to track
pointers.

>> class a (
>>     X & m_x;
>>     ....
>> };

>And how would you deserialize this, given that references are not
rebindable?

Specialization of save/load_construct_data

> >>>  for(...{
>> >>>      X x = *it; // create a copy of
>> >>>      ar << x
>> >>>  }
>> How do we know that one of the x's saved in the loop is not
>> serialized asa pointer somewhere else?

>You keep a set of addresses of all saved objects.

Isn't it just easier and better just to let the serialization system do it
by reformulating the above as:

For(...
 const X & x = *it;
 ar << x
}

>> We have to track ALL x's because we don't know which ones if any are
>> being tracked somewhere else. It could even be in a different module.

>Right, you need to track all addressed while saving, but in archive the
>saves from the above loop need not be marked as tracked.

Currently there is no way (and no need in my opinion) to assign tracking
behavior for each invocation of the << and >> operator.  If you want to
suppress tracking altogether for type X you can assign track_never trait.
In the case the STATIC_ASSERT won't trap - so there you are.

>  const X x;
>  const X& x2 = x;

>are you saying that saving them works differently?

I'm saying that

 const X &x = m_x;
 ar << x;
is different thatn
 const x = m_x
 ar << x;

>> which we are quite comfortable with.  In fact I believe
>>
>>          auto_ptr<const Data> finish()
>>          {
>>                  //auto_ptr<Data> result; // whoops
    auto_ptr<const Data> result;
>>                  // modify result
>>                  return result;
>>          }
>>
>> expresses your intention quite well.  That you're returning an
>> auto_ptr to an object that you don't expect should be changed by
>> anyone who gets the pointer this way.

Except that it does not compile.

>I recall that in earlier versions users simple *could not* serialize a
>pointer to int. Did that change or I am wrong?

It could probably be done by tweaking the serialization traits for int but
that would ripple through the whole program.

Robert Ramey