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