|
Boost Users : |
Subject: Re: [Boost-users] Serialization with pointer to const object
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-07-24 23:06:09
Emil Dotchevski wrote:
> On Fri, Jul 24, 2009 at 4:40 PM, Robert Ramey<ramey_at_[hidden]> 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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net