Re: [boost] [serialization] Regressions?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-06-26 04:15:23

Robert Ramey wrote:
> Peter Dimov wrote:
>> Robert Ramey wrote:
>>> Peter Dimov wrote:

>>> 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.

Right, that's because your operator<< takes a non-const reference. So the 
code above is not prevented by your STATIC_ASSERT trap, but it's still not 
supported by the library. Change the function to return "X const", as a user 
might do when faced with the error, and it will compile, not trap, and 
probably not do what one wants. (The other workaround would be to use a 
named variable and save that. This case will be trapped if the variable is 
not const.)

> I'm not sure why the others compile it.

For backward compatibility; many years ago non-const references to 
temporaries were allowed.

>> 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.

[...]

> 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.

[...]

> 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.

You keep dismissing everything I say. It's a topic for another time; it's 
not about the defaults. It is. The _only_ reason that you had to trap some 
cases is because your defaults don't work for them!

If you change the default behavior to handle these cases, while still 
allowing previous uses to work as they did, you will no longer need to trap 
anything. Which is why I proposed one possible default behavior that seems 
to fit that description, and asked you whether it sounds reasonable.