boost::in_place_factory

Okay. I fail to see the point of the boost::in_place_factory. I think I understood the basics. Or maybe not since I fail to see the advantages.

It drew my attention because I'm actually doing some construction of aggregated objects through copy constructors on the aggregator class. However, I never thought a temporary object would be considered a problem.

This particular section of the documentation confuses me:

Quote:

---

There is a subtle problem with this: since the mechanism used to initialize the stored object is copy construction, there must exist a previously constructed source object to copy from. This object is likely to be temporary and serve no purpose besides being the source

Code:

---

void foo()
{
  // Temporary object created.
  C c( X(123,"hello") ) ;
}

---

A solution to this problem is to support direct construction of the contained object right in the container's storage.

---

How is this a problem?

Because it is inefficient?

Do you have a link to that quote?

> Do you have a link to that quote?

It's at http://www.boost.org/libs/utility/in...ories.html#mot

> Because it is inefficient?

Sure, one object for the price of two. But is that really problematic? The in-place restrictions of the aggregator (has to be correctly aligned and sized) seem to make this only usable for small classes with no STL containers, for instance.

STL containers won't affect the size of your object; sizeof(Class) is always constant and always known at compile time.

>> But is that really problematic?
After reading that link, I think yes, the "problem" is the unnecessary cost of the temporary. The requirement of having a copy constructor seems to be the bigger problem being solved, but I guess that's not what the "subtle problem" refers to.

And, yes, the extra temporary can be problematic. I don't follow your conclusion that this is only usable for small classes, but regardless, even small classes can be expensive to copy.

It appears that the bigger reason for in_place_factory is the removal of the copy constructible requirement, which is very important for classes that cannot be copied correctly (e.g. a class with a reference member variable). That alone would seem to be reason enough to make this useful.

Excellent. Thank you :)