boost::in_place_factory

This is a discussion on boost::in_place_factory within the C++ Programming forums, part of the General Programming Boards category; Okay. I fail to see the point of the boost::in_place_factory. I think I understood the basics. Or maybe not since ...

  1. #1
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,663

    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?
    From now on a large part of your life will be spent finding and correcting your own mistakes.
    And if you are lucky and land yourself a good job, a whole lot more time will be spent finding and correcting other people's mistakes.
    That has to be good, no?

    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,346
    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
    Portugal
    Posts
    7,663
    > 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.
    From now on a large part of your life will be spent finding and correcting your own mistakes.
    And if you are lucky and land yourself a good job, a whole lot more time will be spent finding and correcting other people's mistakes.
    That has to be good, no?

    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
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    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,346
    >> 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
    Portugal
    Posts
    7,663
    Excellent. Thank you
    From now on a large part of your life will be spent finding and correcting your own mistakes.
    And if you are lucky and land yourself a good job, a whole lot more time will be spent finding and correcting other people's mistakes.
    That has to be good, no?

    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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21