'good' smart pointer for factory?

What is a good boost smart pointer to return from a factory?

shared_ptr or scoped_ptr?

I read that shared_ptr is only used in certain circumstances like when putting the pointer into STL containers. But scoped_ptr seems too simple for generic use.

Is there a 'best' smart pointer for generic use?

Scoped cannot be returned, because it has no copy semantics. I would say that scoped_ptr is used only in certain circumstances, not shared_ptr, which is used widely and should be preferred over scoped.

There is no the best one.

At the moment, I think it is std::tr1::shared_ptr. But then std::unique_ptr might be better in general, when the next version of the C++ standard is finalised.

I'll step out on a limb and say that you should return a "dumb" pointer. The factory pattern is usually used in VERY loosely coupled code. Returning any kind of smart pointer will force the caller to use that smart pointer type in his own code. He might not want to.

Quote:

---

Originally Posted by kmdv

Scoped cannot be returned, because it has no copy semantics. I would say that scoped_ptr is used only in certain circumstances, not shared_ptr, which is used widely and should be preferred over scoped.

There is no the best one.

---

I read about this in the google guidelines

http://google-styleguide.googlecode....k/cppguide.xml


"If you actually need pointer semantics, scoped_ptr is great. You should only use std::tr1::shared_ptr under very specific conditions, such as when objects need to be held by STL containers. You should never use auto_ptr."

Quote:

---

Originally Posted by KIBO

I read about this in the google guidelines

http://google-styleguide.googlecode....k/cppguide.xml


"If you actually need pointer semantics, scoped_ptr is great. You should only use std::tr1::shared_ptr under very specific conditions, such as when objects need to be held by STL containers. You should never use auto_ptr."

---

Actually, you should only use boost::scoped_ptr and std::tr1::shared_under very specific conditions: for the former, when you need a smart pointer with a lifetime within some scope; for the latter, when you need a smart pointer with shared semantics.

std::unique_ptr should be used when you need a smart pointer with unique ownership of the object. It is also useful when you need a smart pointer with a lifetime within some scope, since scoped_ptr is and will remain non-standard (at least in the near future).

In this sense, brewbuck's point is a good one. Yet, I would rather return std::unique_ptr since it has minimal overhead and still allows the caller to convert it to whatever other (smart) pointer type is needed, with the peace of mind that RAII is safely used otherwise.

Hm, in my expierience I noticed, that whenever I attempted to use a non-copyable smart pointer, sooner or later I missed that feature and got back to the shared. From my point of view, they are useless as data members because they make the whole class non-copyable. And when it comes to buffers, I use STL container or bare instance (what is point of allocating a single object on heap?), or an own raw vector class for raw data. The only case I would use it would be to make it a result variable. But again, if I return it, I probably copy it somewhere else too.

So my unique_ptr usage is downgraded to the level I do not use it at all.

And I might be wrong, but weak_ptr can't be used with scoped_ptr / unique_ptr?

Quote:

---

Originally Posted by kmdv

And I might be wrong, but weak_ptr can't be used with scoped_ptr / unique_ptr?

---

Yes, it is meant to work with shared_ptr.

Thanks for info, I did not know about unique_ptr that seems to a 'best' choice for returning from a factory indeed withe the most freedom for client programmers

Quote:

---

Originally Posted by kmdv

Hm, in my expierience I noticed, that whenever I attempted to use a non-copyable smart pointer, sooner or later I missed that feature and got back to the shared. From my point of view, they are useless as data members because they make the whole class non-copyable. And when it comes to buffers, I use STL container or bare instance (what is point of allocating a single object on heap?), or an own raw vector class for raw data. The only case I would use it would be to make it a result variable. But again, if I return it, I probably copy it somewhere else too.

So my unique_ptr usage is downgraded to the level I do not use it at all.

And I might be wrong, but weak_ptr can't be used with scoped_ptr / unique_ptr?

---

If you find later that the non-copyable smart pointer is limiting you, then it's probably a sign that your design has flaws in one or another way. Either you did not anticipate what might be required in the design, or it turns out the design simply doesn't work, or you made a mistake.
The smart pointer is usually supposed to catch such mistakes by having proper semantics.

Quote:

---

Originally Posted by KIBO

What is a good boost smart pointer to return from a factory?

---

Hmm, it seems you've put half the answer in the question.
What's wrong with a lowly auto_ptr? The caller is free to take that data and put it into something else.

Quote:

---

Originally Posted by iMalc

What's wrong with a lowly auto_ptr?

---

It will be deprecated in the next version of the C++ standard in favour of unique_ptr, so I am reluctant to suggest it as part of an interface.

I'm throwing my vote in for the suggestion offered by brewbuck.

Why burden a factory with a specific smart pointer when your client could very easily stick it in any reasonable smart pointer after the fact.

Soma

Quote:

---

Originally Posted by laserlight

It will be deprecated in the next version of the C++ standard in favour of unique_ptr, so I am reluctant to suggest it as part of an interface.

---

Oh wow, I didn't know that.

Yeah being a factory method I'm not entirely convinced there is a need to return a smart pointer either. I mean new itself doesn't give you a smart pointer, you have to put it into something. This situation isn't much different.