ansaurus

Question

gcc workaround while using shared_ptr to insert in std::set

Answer 1

A:

void AddIntegers(int& x)
{
...
    iptrSet2.insert(&x);

This probably fails, because there is no implicit conversion form int* to boost::shared_ptr<int>. You'll have to construct it manually (and beware: for one object, only one shared_ptr can be constructed; other pointers must be creaied as copies of this one "master" shared pointer).

jpalecek 2010-06-08 12:52:37

I have tried that, but it still fails. Posted the complete error message and stack. thanks

Mark 2010-06-08 13:22:22

See Mark B's answer.

jpalecek 2010-06-08 17:12:42

Answer 2

+1 A:

Looks like it's having trouble with the conversion from int* to shared_ptr. I think the workaround is fairly simple:

shared_ptr<int> intPtr(&x);
iptrSet2.insert(intPtr);

bshields 2010-06-08 12:52:46

:( It still fails with the same two errors.

Mark 2010-06-08 13:03:24

Answer 3

+5 A:

For (obvious) reason, there is not implicit conversion from T* to shared_ptr<T>.

For example, the following code fails:

int i = 3;
shared_ptr<int> ptr;
ptr = &i;

There is a good reason for that: the shared_ptr OWNS the resources it points to. You cannot blindly throw something into a shared_ptr to get free memory management, you have to make sure that the object is not already owned by something else.

The solution is to use either the constructor or a builder:

shared_ptr<int> ptr(new int(3));

shared_ptr<int> ptr = shared_ptr<int>(new int(3));

shared_ptr<int> made = make_shared<int>(3);

The last method leads to a slightly more compact pointer, though the difference is unlikely to affect you.

I would stress that your example is fishy. Ownership is better enforced right at creation time. In a function like such, chances are someone else has acquired the ownership already and that you're creating a Big Bad Bug.

Matthieu M. 2010-06-08 13:03:46

I tried these, but i still get the same error message. I have posted the exact error message.

Mark 2010-06-08 13:16:40

Answer 4

+3 A:

Your shared_ptr implementation seems very unusual.

Compared to boost/tr1, you have extra converting operators for T** and T*. Implicitly converting to the underlying pointer type (T*) is only going to confuse the compiler.

After I commented out those methods, I had to fix the copy constructor to actually copy member-wise rather than abusing the converting operator. It still won't work as a shared pointer because there's no reference counting.

Then I had to fix operator< to take const shared_ptr<T>& p again because the implicit conversions were causing this to compile, but confusing the compiler on the std::set later on. It got confused because it was trying to construct a shared_ptr but the operator& (I think) caused it to degrade to T** so the type didn't match the type inside the container.

With those changes I was able to get it to successfully compile with g++ 4.2.

EDIT: Well, I was able to write a custom allocator that compiles but it doesn't seem terribly clean and may not even work in all cases.

template <class T>
class sh_ptr_alloc : public std::allocator<T>
{
public:
        typedef size_t     size_type;

      sh_ptr_alloc() throw() { }

      template<typename Tp1>
        sh_ptr_alloc(const sh_ptr_alloc<Tp1>&) throw() { }

      template<typename Tp1>
        struct rebind
        { typedef sh_ptr_alloc<Tp1> other; };

template <class Tp1>
      void
      deallocate(Tp1* p, size_type)
      { ::operator delete(p); }

template <class Tp1>
      void 
      construct(Tp1** p, const shared_ptr<Tp1>& val) 
      { ::new(p) shared_ptr<int>(val); }

template <class Tp1>
      void 
      destroy(Tp1** p) { }
};

The set is then:

typedef std::set<shared_ptr<int>, std::less<shared_ptr<int> >, sh_ptr_alloc<shared_ptr<int> > > IntPtrSet2;

Mark B 2010-06-08 14:33:31

Thanks a lot for your solution. :) The problem is the shared_ptr that I am using is part of the code which I don't have permission to change. A lot of other client code depends on the implicit converting operators. Is there any other workaround without changing shared_ptr?

Mark 2010-06-09 05:56:12

@Mark Understood. But also consider: If a lot of code depends on the implicit conversions, think how much code could be broken unknowingly because the implicit conversions are invoked in unexpected ways?

Mark B 2010-06-09 13:52:52

@Mark B Agreed. I'll push for using a better shared_ptr. Thanks for your solution using custom allocator. :)

Mark 2010-06-09 19:07:13

ansaurus

tags:

views:

answers:

gcc workaround while using shared_ptr to insert in std::set

related questions