[Boost-commit] svn:boost r58433 - sandbox/function/libs/function/doc

Subject: [Boost-commit] svn:boost r58433 - sandbox/function/libs/function/doc
From: dsaritz_at_[hidden]
Date: 2009-12-17 11:36:17

Author: psiha
Date: 2009-12-17 11:36:16 EST (Thu, 17 Dec 2009)
New Revision: 58433
URL: http://svn.boost.org/trac/boost/changeset/58433

Log:
Added a few relevant notes from the "main" boost.devel post.
Text files modified: 
   sandbox/function/libs/function/doc/readme.txt |    31 ++++++++++++++++++++++++++++++-         
   1 files changed, 30 insertions(+), 1 deletions(-)

Modified: sandbox/function/libs/function/doc/readme.txt
==============================================================================
--- sandbox/function/libs/function/doc/readme.txt	(original)
+++ sandbox/function/libs/function/doc/readme.txt	2009-12-17 11:36:16 EST (Thu, 17 Dec 2009)
@@ -31,4 +31,33 @@
 assignement, which, at the point of change or creation has all the type
 information it wants.
 
-You can contact me/"the author" at dsaritz at gmail.com.
\ No newline at end of file
+A few more notes:
+- the default interface and behaviour remain the same (current code should work
+the same without modification with these changes, "or so it seems to me")
+- the empty handler objects are required to satisfy the is_stateless<>
+condition
+- all function objects used with boost::function<> are expected to have a
+nothrow destructor
+- the swap and non-trivial assignement function do not offer the strong
+exception safety guarantee in the special case when one or both of the objects
+at stake is or has (if it is a boost::function<> object "holding" some function
+object) a function object that fits in the function_buffer but does not have a
+nothrow copy constructor and therefore does not have a no-fail move
+operation...in this case it can happen that the final move operation (in the
+swap procedure) from the tmp object to *this can fail and then the attempt to
+restore (move) the original *this from a backup location can also fail leaving
+us with no valid object in *this...in this situation the *this function object
+is cleared (the EmptyHandler is assigned)...as far as i could tell the original
+boost::function<> implementation had the same behaviour...
+- a few more ideas of what can be made a matter of policy: size and alignement
+of the function buffer (perhaps some library uses only complex targets so it
+would benefit if the function_buffer optimization would be eliminated all
+together...on the other some other library would benefit if the buffer would be
+better aligned or enlarged by "just one int" and then no memory allocation
+would take place for that library ...etc...)
+- there is the ever present problem of what to return from empty handlers for 
+non-void and non-default constructible return types...
+...
+
+
+You can contact me/"the author" at dsaritz at gmail.com.