Re: [Boost-users] Serialization and shared_ptr<const X>

From: Anders Wang Kristensen (awk_at_[hidden])
Date: 2007-01-18 20:16:01

Thanks for your answer.

I actually find shared_ptr<const X> quite useful for managing immutable 
reference counted resources.
E.g:

//the resource
class font;
shared_ptr<font> f(new font);

//then a class that uses the font, but isn't allowed to change it, could be:
class some_class
{
public:
    void set_font(const shared_ptr<const font>&);
private:
    shared_ptr<const font> font_;
}

I guess I'll stick with the original solution then.

-- Anders

"Robert Ramey" <ramey_at_[hidden]> wrote in message 
news:eop0ov$ic2$1_at_sea.gmane.org...
> Anders Wang Kristensen wrote:
>> Hi,
>>
>> I sometimes use shared_ptr<const X> to share read-only resources
>> between different classes.
>
> Hmmm - this seems count intuitive to me.  I would expect a pointer
> to a const object point to member object created at construction
> or on the stack.  That is an object which doesn't have to be explictly
> deleted and hence does not require the functionality that share_ptr
> provides.

> Further more- the concept of de-serialization a "const" object also
> seems odd to me.  The whole concept of "const" is that the object
> never changes while it exists.  This would conflict with serialization.
> There is provision for creating "const" object via serialization when
> an object is constructed.  (load_construct_data).
>
> Having said that I realize that there may be justification for this
> that I haven't come upon.  I suspect that it could be addressed
> with const_cast<X &>(x) or something like that.
>
>> However serializing shared_ptr<const X> causes problems as shown in
>> the attached code.
>
> As I think it should.
>
>>
>> Saving is no problem, but loading fails to compile with an error about
>> converting from const to non-const.
>
>> I managed to make it compile and run by splitting serialize into
>> load/save. Save is as before, but in load I deserialize into a
>> shared_ptr<X> (no const) and just assign that to the const version.
>> Is this the preferred way?  It seems like a hack since I'm saving as
>> one type and loading as another, albeit closely related, type.
>
> Well, it seems like a hack to me - not that I'm going to make
> a big deal of this (Let he among who is without sin cast the first 
> stone!).
> But it seems that it should work fine so its ok with me.  The
> extra copy would bother me so I would try "const_cast" as described above.
>
> Also, you might want to double check your motivation for using
> "const" in the first place.
>
> Robert Ramey