Thread: boost::in_place_factory

  1. #1
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446

    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:

    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?
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  2. #2
    Registered User
    Join Date
    Jan 2005
    Posts
    7,366
    Because it is inefficient?

    Do you have a link to that quote?

  3. #3
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    > 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.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  4. #4
    Registered User
    Join Date
    May 2003
    Posts
    1,619
    STL containers won't affect the size of your object; sizeof(Class) is always constant and always known at compile time.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  5. #5
    Registered User
    Join Date
    Jan 2005
    Posts
    7,366
    >> 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.

  6. #6
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Excellent. Thank you
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

Popular pages Recent additions subscribe to a feed