610. Suggested non-normative note for C++0x

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").