Re: counted_base vs. sp_counted_base - boost 1.30.0 functionality deprecated

4 Jun 2003

      --- In Boost-Users@yahoogroups.com, "Anders Hybertz" 
<anders.hybertz@m...> wrote:
...
Hi
Up to and including version 1.29.0 of the boost library I had an 
object which inherited from boost::counted_base, and could 
actually 
within that object control when it should be deleted. The object 
spawned a thread which was listening on a queue, when there was 
pushed an shutdown message on the queue, I could safely delete the 
object.
In boost 1.30.0 the counted_base changed name and namespace to 
boost::detail::sp_counted_base, but the way it works also changed -
...
so now my object's destructor is called whenever it's going out of 
scope - which I don't want.
Any ideas - or should I provide a small sandbox example
Thanks in advance
Anders Hybertz
Just to follow up on my own mail. I have now attached a 
small 'almost' complete example which works in boost 1.29.0

------------------------------------------------------------
#include <iostream>
#include <boost/shared_ptr.hpp>

class Test : public boost::counted_base
{
public:
    Test() :  boost::counted_base( 1, 1 )
    {
        std::cout << "Test::Test" << std::endl;

        // Start the thread
    }

    void ThreadMethod()
    {
        bool active( true );
        while( active )
        {
            // active = someQueue.Pop()
        }
        release();
    }
    ~Test()
    {
        std::cout << "Test::~Test" << std::endl;
    }
};

typedef boost::shared_ptr<Test>         TestPtr;

int main(int argc, char* argv[])
{
    {
        TestPtr    spTest( new Test );
    }

    // Test destructor is not being called even though that it has 
left scope

    // Stop thread and clean up etc.

    return 0;
}
------------------------------------------------------------

The main purpose is that the Test destructor is not called before 
the thread actually finishes.

Changing boost::counted_base to boost::detail::sp_counted_base for 
boost 1.30.0 does not provide this feature.

Is there another way I cn ensure that the destructor is never being 
call - but without modifying the interface, the user should not be 
avare of the hidden details.

Thanks in advance

Anders Hybertz