on Tue Nov 11 2008, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

when this first came up, it thought that it would be possible to do this. Now that I think about this, I don't see that its possible.

The things that occur to me that could be done would be:

a) include the hack of creating a temporary variable on the stack.

My concern this was that objects are tracked by address. But if the type of the object is not tracked then there would be no problem. So I would use BOOST_STATIC_ERROR( implementation_level<T><= object_serializable )

b) the above could be included in an rval wrapper.

c) the above could be included in the library itself.

A way to temporarily "turn off" tracking hasn't occured to me yet. I'm leaving aside the side effects that such a faclity might cause.

Thanks for your answer. When I asked, it was much more important to me that I find out what the current behavior was than it was to have a new feature. So, again, thanks. I have what I need to do my job. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

on Wed Nov 12 2008, joaquin-AT-tid.es wrote:

I think something to this effect can be implemented resorting to <drumroll>helper support</drumroll>. Non-tested pseudocode follows. The idea is not to supress tracking (which can't be done) but rather to move stack-based objects to a safe location so that Boost.Serialization does not get confused by objects with potentially the same stack address.

template<typename T> struct non_tracking { non_tracking():p(0){} non_tracking(const T& t):p(&t){}

const T& get()const{return *p;}

const T* p;

struct helper { typedef std::list<T> table_type; table_type table; };

template<class Archive> void save(Archive & ar,const unsigned int)const { helper::table_type& table=ar.get_helper<helper>().table; table.push_back(*p); ar<<table.back(); }

template<class Archive> void load(Archive & ar,const unsigned int) { helper::table_type& table=ar.get_helper<helper>().table; T t; ar>>t; ^^^^^

Not that I really need this feature, but what is going to prevent the library from doing the usual thing it does when deserializing T here? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

on Wed Nov 12 2008, joaquin-AT-tid.es wrote:

David Abrahams escribió:

...

Not that I really need this feature, but what is going to prevent the library from doing the usual thing it does when deserializing T here?

The call to reset_object_address than ensues: as every different object of non_tracking<T> gets reassigned to a unique element in the helper table, it's impossible that Boost.Serialization tracking capabilities mistakenly take one object t1 as the same as a previous t2 just because their (stack-based) addresses coincide. This is not supressing tracking, but effectively implies that it'll never impact the serialized stuff.

It impacts the *size* of the serialized stuff, which is my only motivation for turning off tracking. -- Dave Abrahams BoostPro Computing http://www.boostpro.com