Re: [boost] [serialization] Regressions?

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-06-25 22:59:47

Peter Dimov wrote:
> Robert Ramey wrote:
>> Peter Dimov wrote:
>>> Robert Ramey wrote:
>>>
>>> There are cases where you only care about the value being saved, not
>>> its identity. You want '4' in the archive, you don't care which
>>> specific '4'.
>>
>> That's why the STATIC_ASSERT doesn't trap if the type is marked as
>> "track_never".  For such items where you only care about the value
>> the "track_never" trait should be set for efficiency reasons if
>> nothing else. The case in my mind was something like pixels in a
>> photograph.
>>
>> So I would amplify my statement above that I can't understand why
>> someone would use the above on an type that might track the address.
>
> For several reasons, the most important one being that tracking is on
> by default.

Thats why I like the trapping behavior.  It will indicate that the default -
track_selectively - is probably not appropriate for this case.

BTW - I thought a little more about your example:

#include <fstream>
#include <boost/archive/text_oarchive.hpp>
#include <boost/static_assert.hpp>
class X {
};
X construct_X_from(int i);
int main(){
std::ofstream os("file");
boost::archive::text_oarchive oa(os);
int i;
// the following traps with vc 7.1
// fails to compile with gcc 3.3 and borland
// compiles - doesn't trap with comeau - I believe that it traps
// but BOOST_STATIC_ASSERT doesn't work for comeau in this case
oa << construct_X_from(i);
}

sure enough, it fails to compile on at least a couple of compilers.
Apparently those compilers don't like taking a reference to something on the
argument stack.  So with these compilers the whole issue of the trap never
presents itself.  This behavior seems correct to me.  I'm not sure why the
others compile it.

> But more fundamentally, address tracking is not a property of the type.

Maybe - maybe not.  I would say that's a topic for another time.

>It is quite possible that the same type X is used in one serialization
> session as non-trackable and in another as trackable. The author of X
> doesn't know how the type will be used, so he can't mark it as
> track_never. It becomes
> the responsibility of the person who actually serializes X to mark it
> appropriately

LOL - I'm sure that marking every usage of << as to whether it should be
tracked or not would be very popular.  In fact the default is almost always
what on wants.  The trap is to highlight likely cases where it may not be.

> Most of these users of both the serialization library and X are very
> likely to not mess with the default tracking level; even if they do,
> they might forget about a type or two; and sometimes they'll never
> see the X being serialized because it might only be part of another
> object Y.

again - generaly the defaults are what most people would want.   No one has
raised any issue regarding the defaults until now.

> I think that the default behavior on a sequence of two saves with the
> same address should be to write the two objects, as if address
> tracking isn't on. If later a pointer to that address is saved, an
> exception should occur. Or more generally,
>
> - one value save, then N pointer saves sharing the same address
> should be
> OK;
>
> - M pointer saves sharing the same address should be OK; (*)
>
> - K value saves sharing the same address should be OK and result in K
> copies in the archive;

Currently you'll only get one copy for this case unless you suppress
tracking.

>
> - all other sequences raise an exception at first opportunity.
>
> Is there any reasonable use case which is prohibited by the above
> rules?
>
> (*) This promotes questionable coding practices but is consistent
> with the current behavior. :-)

Accept as noted above, that's how it works now.

The question isn't really the defaults.  But whether my attempts to trap
likely cases where they should be overriden are mis-guided.

Robert Ramey