By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,129 Members | 1,331 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,129 IT Pros & Developers. It's quick & easy.

Detaching primitive from boost::shared_ptr?

P: n/a
I have a boost::shared_ptr and want to detach the primitive pointer
within it so I can keep using it even after the shared_ptr is
destroyed.

Is there a way to do this?

Aug 2 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Sean wrote:
I have a boost::shared_ptr and want to detach the primitive pointer
within it so I can keep using it even after the shared_ptr is
destroyed.

Is there a way to do this?

Copy the shared_ptr to a local shared_ptr that has the same scope
as the raw pointer.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.
Aug 2 '05 #2

P: n/a
In message <11**********************@g49g2000cwa.googlegroups .com>, Sean
<sj*********@yahoo.com> writes
I have a boost::shared_ptr and want to detach the primitive pointer
within it so I can keep using it even after the shared_ptr is
destroyed.

Is there a way to do this?


Why would you want to? The whole point of shared pointers is to avoid
this kind of unsafe manipulation of raw pointers.

If you want to share the pointed-to object, just take a copy of the
shared_ptr in another shared_ptr. That's what the "shared" in the name
means. For as long as there's at least one shared_ptr pointing to it,
the object won't be deleted - *provided* you don't do unsafe tricks with
raw pointers to the same object.

--
Richard Herring
Aug 3 '05 #3

P: n/a
* Sean:
I have a boost::shared_ptr and want to detach the primitive pointer
within it so I can keep using it even after the shared_ptr is
destroyed.
That is not a good idea; can you see why?

Is there a way to do this?


Yes.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Aug 3 '05 #4

P: n/a
Agreed. It's not a good idea. However, I still need to do it. Can you
post sample code on how to do it?

thank you.

Aug 4 '05 #5

P: n/a

"Sean" <sj*********@yahoo.com> wrote in message
news:11**********************@g47g2000cwa.googlegr oups.com...
Agreed. It's not a good idea. However, I still need to do it. Can you
post sample code on how to do it?


Can you post sample code on why you think you need to do it?

Thanks, Jeff
Aug 4 '05 #6

P: n/a
* Sean:
Agreed. It's not a good idea. However, I still need to do it. Can you
post sample code on how to do it?


Note first that normally you'd just use another shared_ptr to keep a
reference to the original's referred object.

And when that isn't feasible, you'd normally use boost::weak_ptr.

I'm therefore almost certain that what you're trying to do is Very Bad
Design (TM), that you could very easily solve the problem by improving the
design, but if you absolutely want to live extremely dangerously, e.g.

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

class X
{
public:
typedef boost::shared_ptr<X> AutoPtr;
static AutoPtr instance(){ return AutoPtr( new X, &destroy ); }
~X(){ std::cout << "Destroyed" << std::endl; }
X* extendedLifetime() { myExtendedLife = true; return this; }
private:
bool myExtendedLife;
X(): myExtendedLife( false ) { std::cout << "Created" << std::endl; }
static void destroy( X* p ) { if( !p->myExtendedLife ){ delete p; } }
};

void doStuff( X::AutoPtr ) {} // Whatever.

X* aUsedNewX()
{
X::AutoPtr p( X::instance() );
doStuff( p );
return p->extendedLifetime();
}

int main()
{
// C-oriented calling code.
X* p = aUsedNewX();
std::cout << "main()" << std::endl;
delete p;
}

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Aug 4 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.