This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.
Section: 22.10.17.3.2 [func.wrap.func.con], 99 [tr.func.wrap.func.con] Status: CD1 Submitter: Scott Meyers Opened: 2006-11-02 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [func.wrap.func.con].
View all issues with CD1 status.
Discussion:
My suggestion is that implementers of both tr1::function and its official C++0x successor be explicitly encouraged (but not required) to optimize for the cases mentioned above, i.e., function pointers and small function objects. They could do this by using a small internal buffer akin to the buffer used by implementations of the small string optimization. (That would make this the small functor optimization -- SFO :-}) The form of this encouragement could be a note in the standard akin to footnote 214 of the current standard.
Dave Abrahams notes:
"shall not throw exceptions" should really be "nothing," both to be more grammatical and to be consistent with existing wording in the standard.
Doug Gregor comments: I think this is a good idea. Currently, implementations of tr1::function are required to have non-throwing constructors and assignment operators when the target function object is a function pointer or a reference_wrapper. The common case, however, is for a tr1::function to store either an empty function object or a member pointer + an object pointer.
The function implementation in the upcoming Boost 1.34.0 uses the "SFO", so that the function objects for typical bind expressions like
bind(&X::f, this, _1, _2, _3)
do not require heap allocation when stored in a boost::function. I believe Dinkumware's implementation also performs this optimization.
Proposed resolution:
Revise 20.5.14.2.1 p6 [func.wrap.func.con] to add a note as follows:
Throws: shall not throw exceptions if f's target is a function pointer or a function object passed via reference_wrapper. Otherwise, may throw bad_alloc or any exception thrown by the copy constructor of the stored function object.
Note: Implementations are encouraged to avoid the use of dynamically allocated memory for "small" function objects, e.g., where f's target is an object holding only a pointer or reference to an object and a member function pointer (a "bound member function").