Compilation of serializing shared_ptr<const Object> fails

[visa.jokelainen@…]

Compilation of code that includes serialization of shared_ptr<const Object> fails with Boost 1.56.0 with error:

/usr/include/boost/smart_ptr/shared_ptr.hpp:323:25: note:   no known conversion for argument 1 from ‘const boost::shared_ptr<const TestClass>’ to ‘const boost::shared_ptr<void>&’

This works with Boost 1.55.0 and earlier versions. Tested on Arch Linux with clang 3.4.2 and g++ 4.9.1.

Here's a little test to replicate the problem:

#include <fstream>

#include <boost/archive/text_iarchive.hpp>
#include <boost/serialization/shared_ptr.hpp>

#include <boost/make_shared.hpp>


class TestClass
{
public:

    TestClass(int i) : _i(i) {}
    
private:
    
    friend class boost::serialization::access;

    TestClass() {}

    template<class Archive>
    void serialize(Archive & ar, const unsigned int version)
    { 
        ar & _i;
    }

    int _i;
};

typedef boost::shared_ptr<TestClass> ClassPtr;
typedef boost::shared_ptr<const TestClass> ConstClassPtr;

int main(int argc, char* argv[])
{    
    ClassPtr ptr = boost::make_shared<TestClass>(13);
    ConstClassPtr cPtr = boost::make_shared<const TestClass>(42);

    {
        std::ifstream ifs("test");
        boost::archive::text_iarchive ia(ifs);

        ia >> ptr; // This works
        
        ia >> cPtr; // This doesn't
    }
    
    return 0;
}

[visa.jokelainen@…]

The problem sounds a lot like regression of this previous ticket: ​https://svn.boost.org/trac/boost/ticket/3123

[Robert Ramey]

Actually this change looks like an improvement to me.

a const TestClass is something that shouldn't be modifiable

ia >> cPtr would do just that.

I don't remember any specific change which would affect this, but the current behavior seems to be the correct one to me.

[Robert Ramey]

see ​https://svn.boost.org/trac/boost/ticket/3123

[reder <rouge.richard@…>]

This is a regression. Not being able to serialize a shared_ptr<const Object> is indeed very painful. Ticket 3123 shows it is not absurd: imagine I have a

typedef map<string,shared<book>> library;

Since I do not want people to write on the books, I'd prefer a

typedef map<string,shared<const book>> library;

and be able to write/load the contents of my library.

Anyhow, it seems to be just a matter of changing line 59 of serialization/shared_ptr_helper.cpp from

  SPT<void> // address shared ptr to single instance

to

  SPT<const void> // address shared ptr to single instance

to regain previous behaviour (if one can check extensively).

[tonvandenheuvel@…]

I can confirm the fix proposed by reder works for me, although I have not checked this extensively.

[chris@…]

This regression currently prevents building Cufflinks; the author is disinclined to work around the problem. I can't link the issue directly due to the spam trap, but google "cufflinks boost serialization".

[Robert Ramey]

note: already checked into master. Correction will appear in next boost release

[boost@…]

Which commit fixed this problem? I would like to try to backport it to boost 1.57.0 in MacPorts.

[boost@…]

I tested with boost 1.58.0 beta 1, released March 16, 2015, and the problem remains.

[boost@…]

I tested with boost 1.58.0, released April 17, 2015, and the problem remains.

If the fix was supposed to be to change SPT<void> to SPT<const void> in ​https://github.com/boostorg/serialization/blob/master/include/boost/serialization/shared_ptr_helper.hpp, that has not occurred.

[anonymous]

OK - I double checked - I fixed this again - I'm not sure what happened the first time

[boost@…]

Could you please post a link to the commit where you fixed it, so that I can backport it to boost 1.58.0 in MacPorts? Thanks.

[xnox]

Is this the fix for this issue?

​https://github.com/boostorg/serialization/commit/010055816681a003a8090d105ea5ab385bb87bf8

[Robert Ramey]

I believe so