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

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

Emil Dotchevski wrote:

On Fri, Jul 24, 2009 at 4:40 PM, Robert Ramey wrote:

...

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

Probably the reason why it doesn't make sense to you but it makes sense to me is that you're looking at serializing a pointer as a mutable operation on the pointee, whereas I look at it as a mutable operation on the pointer itself.

Please don't get me wrong, I wouldn't want the following code to compile:

struct foo { int const m_x; };

.... ar << a_foo.m_x;

But I think that the code below should just work:

struct foo { int const * m_x; };

Maybe - now that I think about it. the library creates a NEW object when it loads a pointer so one could argue that the "const" isn't being violated. An alternative interpretation of "serialization" would have been that ar >> m_x would be equivalent to ar >> *m_x in which case the "const" would be violated. Also the issue comes up with wrappers as well. xml, binary object. Truth is, I never really thought about this in systematic way and just sort of applied it on a case by case basis as I went along. Someday I'll look at it more carefully.

.... ar << a_foo.m_x;

Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

Emil Dotchevski wrote:

On Fri, Jul 24, 2009 at 8:06 PM, Robert Ramey wrote:

...

Emil Dotchevski wrote:

...

On Fri, Jul 24, 2009 at 4:40 PM, Robert Ramey wrote: would be equivalent to ar >> *m_x in which case the "const" would be violated.

At the time the object needs to be instantiated and read, instead of dealing with a T const * p as:

p=new T; ar >> *p;

what's wrong with:

T * tmp=new T; ar >> * tmp; p=tmp;

This reminded me of the same issue with shared_ptr<const T> https://svn.boost.org/trac/boost/ticket/3123 I'm not sure Robert is applying const correctness correctly here. There is no "const violation" here. If there was, you'd see a const_cast in the patch somewhere. -- Sohail Somani http://uint32t.blogspot.com

The question is under consideration. It won't be resolved for a while. And such resolution might or might not mean a change. To get over the hump, you might want to just use a const_cast. Robert Ramey Soumen wrote:

So finally to summarize it means that for now I cannot serialize pointers to const obj. And I need to update my code to throw away the const. Is that correct?

Regards, ~ Soumen

Sohail Somani-2 wrote:

...

Emil Dotchevski wrote:

...

On Fri, Jul 24, 2009 at 8:06 PM, Robert Ramey wrote:

...

Emil Dotchevski wrote:

...

On Fri, Jul 24, 2009 at 4:40 PM, Robert Ramey wrote: would be equivalent to ar >> *m_x in which case the "const" would be violated.

At the time the object needs to be instantiated and read, instead of dealing with a T const * p as:

p=new T; ar >> *p;

what's wrong with:

T * tmp=new T; ar >> * tmp; p=tmp;

This reminded me of the same issue with shared_ptr<const T> https://svn.boost.org/trac/boost/ticket/3123

I'm not sure Robert is applying const correctness correctly here.

There is no "const violation" here. If there was, you'd see a const_cast in the patch somewhere.

-- Sohail Somani http://uint32t.blogspot.com

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

use a const_cast. Robert Ramey Soumen wrote:

Hi Robert,

I guess there's no direct way through which I can throw away const-ness during serialization. One way is to modify my class to remove const-ness for the pointee or use some temporary var which is non-const and serialize using that. Right? Or is there a better way - in that case I'll follow that till the issue gets resolved, hopefully, in boost.

Regards, ~ Soumen

Robert Ramey wrote:

...

The question is under consideration. It won't be resolved for a while. And such resolution might or might not mean a change. To get over the hump, you might want to just use a const_cast.

Robert Ramey

Soumen wrote:

...

So finally to summarize it means that for now I cannot serialize pointers to const obj. And I need to update my code to throw away the const. Is that correct?

Regards, ~ Soumen

Sohail Somani-2 wrote:

...

Emil Dotchevski wrote:

...

On Fri, Jul 24, 2009 at 8:06 PM, Robert Ramey wrote:

...

Emil Dotchevski wrote: > On Fri, Jul 24, 2009 at 4:40 PM, Robert Ramey > wrote: would be equivalent to ar >> *m_x in which case the "const" would be violated.

At the time the object needs to be instantiated and read, instead of dealing with a T const * p as:

p=new T; ar >> *p;

what's wrong with:

T * tmp=new T; ar >> * tmp; p=tmp;

This reminded me of the same issue with shared_ptr<const T> https://svn.boost.org/trac/boost/ticket/3123

I'm not sure Robert is applying const correctness correctly here.

There is no "const violation" here. If there was, you'd see a const_cast in the patch somewhere.

-- Sohail Somani http://uint32t.blogspot.com

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users