c++11 std::shared_ptr + boost::serialization [dupl

2020-06-03 05:42发布

问题:

Hi has anybody already managed to serialize a C++11 std::shared_ptr with boost::serialization. There are lots of obsolete posts out there but none with an acceptable solution. I am not going into discussion why I want to use the std::shared_ptr just accept it!

I found this other post: boost serialize and std::shared_ptr but it does not answer my problem how to serialize the std::shared_ptr it only suggests to uses the boost::shared_ptr which is not possible in my case.

And this post How can boost::serialization be used with std::shared_ptr from C++11? does also only recommend to use boost::shared_ptr.

I would be interested if anybody has already found a work around that manages to serialize the std::shared_ptr.

I finally found a solution to my problem see https://stackoverflow.com/a/14999396/2039157 for my answer.

回答1:

Isn't it possible to "just" create a serializer<< and deserializer>> that will "just" turn the shptr-serialization into object-pointer serialization? If not done yet, I'm almost sure that this is possible in < 100 lines of code.

Also, I know that you have specified not to ask, but still I will: When you try to serialize "X" variable that is shptr, why can't you just serialize dereferenced *shptr ? That doesn't seem enough difference for me to bother with adding serialization for smartptrs.. Hm.. ok. esthetics. But still I think it is doable.

Anyways, however you can hit another wall: if you use class inheritance and if you carry along the objects within shptr via pointer to the base class, you will have the obvious problem that the serializer will not know what actually it is ordered to serialize. But that's a classic problem for serialization without RTTI, that, well, you hve to somehow solve, but that's not the problem of shptrs.

disclaimer: the last time I used boost::serialization was few years ago. I did not actually try to serialize shptr, but from what I remember, that was quite an open framework, relatively easy to extend for any custom type, so I assume shptrs are no better than my weird-classes-that-I-managed-to-serialize :)