std::tr1::shared_ptr question

[StainedBlue]

How can I add a shared_ptr to a container of shared_ptrs of some existing object?

Example of what I'm trying to accomplish here:

#include <algorithm>
#include <iostream>
#include <memory>
#include <vector>

class Foo{};

int main()
{
	std::vector<Foo> foos;
	foos.push_back(Foo());
	foos.push_back(Foo());
	foos.push_back(Foo());

	std::vector<std::tr1::shared_ptr<Foo>> fooPointers;

	std::for_each
	(
	    foos.begin(), foos.end(),
		[&fooPointers](Foo foo)
		{
			fooPointers.push_back( /* How do I add an existing foo as a shared_ptr here? */ );
		}
	);

	return 0;
}

[pianorain]

IMO, you shouldn't. shared_ptr assumes that it has ownership of the object it points to. You can either make sure your objects are never stored outside of a shared_ptr or make a new copy of your object so that the copy is managed by the shared_ptr.

[StainedBlue]

Ok, cool. Here's the example revised, but is there a way to eliminate the ugly cast where the Foo objects are first created?

#include <algorithm>
#include <iostream>
#include <memory>
#include <vector>

class Foo{};

int main()
{
	std::vector<std::tr1::shared_ptr<Foo>> foos;
	foos.push_back((std::tr1::shared_ptr<Foo>)new Foo());
	foos.push_back((std::tr1::shared_ptr<Foo>)new Foo());
	foos.push_back((std::tr1::shared_ptr<Foo>)new Foo());

	std::vector<std::tr1::shared_ptr<Foo>> fooPointers;

	std::for_each
	(
	    foos.begin(), foos.end(),
		[&fooPointers](std::tr1::shared_ptr<Foo> foo)
		{
			fooPointers.push_back(foo);
		}
	);

	return 0;
}

[laserlight]

is there a way to eliminate the ugly cast where the Foo objects are first created?

Instead of using a C-style cast, use the appropriate constructor directly, though this would involve a mere shifting of parentheses and can be regarded as changing to use a function-style cast

[VirtualAce]

What pianorain is getting at is that when the shared pointer goes out of scope the vector has no way of knowing this and will now have a pointer to an area of memory that has been cleaned up. The pointer must be removed from the vector and the only way to do this is to either notify the container of the event or choose a different design.

[StainedBlue]

What pianorain is getting at is that when the shared pointer goes out of scope the vector has no way of knowing this and will now have a pointer to an area of memory that has been cleaned up. The pointer must be removed from the vector and the only way to do this is to either notify the container of the event or choose a different design.

Thanks. Yea I guess my original confusion was more to do with what a shared_ptr did. I originally thought of it more as a managed pointer, than a managed object (hence the syntactic error in my original post). In my case, rewriting the original containers as containers of shared_ptrs was no big deal, and literally took me seconds to rewrite.

@laserlight

yea the cast i posted is definitely silly, and a quick google of shared_ptr got me a quick tutorial of its consttructor. Thanks.

[VirtualAce]

In my case, rewriting the original containers as containers of shared_ptrs was no big deal, and literally took me seconds to rewrite.

Eh? I don't follow.

[StainedBlue]

Eh? I don't follow.

In my OP, i had a vector of foos, which i was trying to "convert" to shared_ptrs for the "fooPointers" vector (a vector of shared_ptrs).

in my second post, i changed the original vector, to a vector of shared_ptrs as well, eliminating the need for a conversion between an already owned object, and a shared_ptr (which assumedly can't be done).

laserlight pointed out that the cast was indeed in bad taste, and suggested I simply use the shared_ptr constructor instead.

[CornedBee]

On a side note, if you need a shared_ptr referring to an object that it doesn't own, you can give the shared_ptr a null deleter.

std::shared_ptr<Foo> ptr(&foo, [](Foo*){});

Also, since you're using lambdas, you apparently have an 0x-enabled compiler, so you should be able to use std::shared_ptr directly; no need to go the tr1 route. Perhaps your compiler even provides make_shared, which would make the code prettier:

std::vector<std::shared_ptr<Foo>> foovec;
foovec.push_back(std::make_shared<Foo>());

It's also slightly more efficient.

If you don't actually need shared ownership, though, I would strongly recommend using a boost:tr_vector instead of a vector of shared_ptrs. I find its interface to be much more convenient.

[StainedBlue]

On a side note, if you need a shared_ptr referring to an object that it doesn't own, you can give the shared_ptr a null deleter.

std::shared_ptr<Foo> ptr(&foo, [](Foo*){});

Also, since you're using lambdas, you apparently have an 0x-enabled compiler, so you should be able to use std::shared_ptr directly; no need to go the tr1 route. Perhaps your compiler even provides make_shared, which would make the code prettier:

std::vector<std::shared_ptr<Foo>> foovec;
foovec.push_back(std::make_shared<Foo>());

It's also slightly more efficient.

If you don't actually need shared ownership, though, I would strongly recommend using a boost:tr_vector instead of a vector of shared_ptrs. I find its interface to be much more convenient.

All very nice suggestions. Thank you. The make_shared make things a lot cleaner.

[VirtualAce]

Lambdas, while very cool, have some of the ugliest syntax I've ever seen.

[Elysia]

I think they look fine. You may need to "prettify" the source code when using them, though, or it may end up looking like crap. I mean, they're pretty much native function syntax.

[StainedBlue]

Lambdas, while very cool, have some of the ugliest syntax I've ever seen.

While just a matter of opinion, I agree c++ lambdas are hideous when you compare them to say c# lambdas. But the syntax is growing on me slowly.

[pianorain]

Just thought I'd share this link of shared_ptr programming techniques. The article includes the null deleter technique CornedBee pointed out.