Emil Dotchevski wrote:
IMO even after the serialization library dereferences the pointer-to-const, it should const_cast it to serialize the object, because in the typical case the object is mutable. For example, if you have:
int const * p=new int(42);
So p->member of p should fail to compiler while ar << p should? Doesn't make sense to me. I think it's a very bad idea to try to make things "just work" when it means changing the behavior from what is written to what one would think is a " rather safe bet". If a programmer writes something that can be seen as ambiguous, there are two approaches to the issue: a) The old fashion way - trap as an error and require that the ambiguity be resolved before contining. b) The new fashion way - a ignore the stated intention of the programmer and help him out by doing what you think he should want. I realize that this is the current fashion. And it' one of the main sources of frustration with modern sofware of all types - from microsoft word to bjam. I ofen find my self trying to figure out what to do by experiment which sucks up a huge amount of time. One man's rant. Sorry. Robert Ramey
the object p points to is mutable and const_cast is well defined. You'd have to do:
int const * p=new int const(42);
to get a const object, in which case const_cast would be undefined behavior, but it seems that this would be extremely rare. Granted, just looking at an int const * p you don't know if the object it points to is mutable or not, but I think that const_cast is a rather safe bet in this case and Soumen is correct to expect the serialization of a pointer-to-const to "just work."
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Fri, Jul 24, 2009 at 1:10 PM, Robert Ramey
wrote: Hmmm - good point. In the past I sort of made this decision in an ad-hoc way without thinking too much about it.
Thinking about now.
const * A m_a
is a pointer to a const object. I would not expect the following to work
ar << m_a
I would not expect it to trap at the right level- but at the lower level after m_a is de-referenced to a const A & and THAT is serialized.
I'm not sure where it's traping now though.
Robert Ramey
Emil Dotchevski wrote:
But in his case the object he is serializing (the pointer itself) isn't const. In addition, in the typical use case the object the pointer points to is also mutable. Shouldn't the const_cast be in Boost Serialization?
Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Fri, Jul 24, 2009 at 9:33 AM, Robert Ramey
wrote: Hmm - a const object is one that can't be changed once created. If you think about it, this conflicts with what serialization is. If in spite of this, you still want to do it, it is possible. Use const_cast. Also there information in the documentation regarding this.
Robert Ramey
Soumen wrote:
Hi,
I'm using gcc 4.2.2 and boost 1.35. If I try to serialize pointer to some const objects, I'm getting compilation problem. Is there any limitation? Or I need to do certain things differently? I couldn't figured any solution over net. If there already exist any topic which points to solution, please point me to that. Otherwise, guide me to resolve the problem at hand. I'm new to boost.
Say, my data member in the class myClass is
const myType *ptr;
In the serialize() routine, I'm doing it in following way:
template< class Archive > void myClass::serialize(Archive &ar, const unsigned int version) { ar & ptr;
// I've tried "ar & const_cast< myType* >(ptr)" and // "ar & (myType *) ptr" as well - it didn't work
/* serialize other members */
}
Regards, - Soumen
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users