Scott Meyers wrote:
> 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 :-})

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.

So I agree with you; a non-normative note encouraging this optimzation
would be a Good Thing.

  Cheers,
  Doug

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Douglas Gregor wrote:
> Scott Meyers wrote:
>> 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 :-})
>
> 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.
>
> So I agree with you; a non-normative note encouraging this optimzation
> would be a Good Thing.

The practical way to make that happen is to write proposed wording.
Given the current workload of LWG members getting ready for C++0x, even
the best ideas may well not happen if they are not accompanied by
proposed wording.

--Beman

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Beman Dawes wrote:
 > The practical way to make that happen is to write proposed wording.

Okay, to get the ball rolling, I propose the following addition to TR1
and to the corresponding section of the C++0x draft (to which I have no
access).

Revise 3.7.2.1/6 to include a footnote as follow (only the footnote is
new -- the text of 3.7.2.1/6 is unchanged):

   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[*].

   [*] 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").

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

usenet@aristeia.com (Scott Meyers) writes:

> Beman Dawes wrote:
>> The practical way to make that happen is to write proposed wording.
>
> Okay, to get the ball rolling, I propose the following addition to TR1
> and to the corresponding section of the C++0x draft (to which I have no
> access).
>
> Revise 3.7.2.1/6 to include a footnote as follow (only the footnote is
> new -- the text of 3.7.2.1/6 is unchanged):
>
>   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[*].

Hmm, I know it's not your wording, Scott, but "shall not throw
exceptions" should really be "nothing," both to be more grammatical
and to be consistent with existing wording in the standard.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers wrote:

>... the C++0x draft (to which I have no access).

The latest draft of the Working Paper is always available in the
"papers" section of the committee web site.

At the moment, it is
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf

--Beman

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

A tr1::function object can be used to hold a function object of
arbitrary size, and as such it can be expected to dynamically allocate
memory to hold the function object.  This appears to be what the Boost
implementation does;  I haven't tested any others.

It strikes me that it will likely be uncommon to hold large function
objects, if for no other reason than large function objects don't play
well with the STL's use of pass-by-value for function objects.  More
specifically, I expect that in many cases, tr1::function objects will
hold only a function pointer or a function object consisting of a member
function pointer and an object pointer (i.e., a bound member function).
     It would be nice if such objects used no heap memory, as my simple
tests show that the Boost::implementation of tr1::function holding a
bound member function has a significantly higher runtime cost than a
tr1::function-like implementation that doesn't support arbitrary
function objects (e.g., Don Clugston's FastDelegates
(http://www.codeproject.com/cpp/FastDelegate.asp)).  Presumably this is
due to the use of heap memory, but, to be honest, I haven't definitively
established that that is the case.  Then again, I'm only proposing a
non-normative note :-)

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.  That footnote says:

   "It is intended that a.allocate be an efficient means of allocating
   a single object of type T, even when sizeof(T) is small.")

Comments on this idea?

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]