Serialization and shared_ptr<const X>
Hi,
I sometimes use shared_ptr<const X> to share read-only resources between
different classes.
However serializing shared_ptr<const X> causes problems as shown in the
attached code.
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.
Thanks.
-- Anders
#include
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
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"
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) 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
participants (2)
-
Anders Wang Kristensen -
Robert Ramey