[Boost-commit] svn:boost r73876 - sandbox/conversion/libs/conversion_ext/doc

Subject: [Boost-commit] svn:boost r73876 - sandbox/conversion/libs/conversion_ext/doc
From: vicente.botet_at_[hidden]
Date: 2011-08-18 01:55:00

Author: viboes
Date: 2011-08-18 01:54:50 EDT (Thu, 18 Aug 2011)
New Revision: 73876
URL: http://svn.boost.org/trac/boost/changeset/73876

Log:
conversion: added lvalue.hpp and implicitly.hpp files
Text files modified: 
   sandbox/conversion/libs/conversion_ext/doc/conversion.qbk |    12 +++++++++++-                            
   1 files changed, 11 insertions(+), 1 deletions(-)

Modified: sandbox/conversion/libs/conversion_ext/doc/conversion.qbk
==============================================================================
--- sandbox/conversion/libs/conversion_ext/doc/conversion.qbk	(original)
+++ sandbox/conversion/libs/conversion_ext/doc/conversion.qbk	2011-08-18 01:54:50 EDT (Thu, 18 Aug 2011)
@@ -112,6 +112,8 @@
 
 [*Boost.Conversion] provides a library-based solution for these missing language features, shows its own limitations and propose some library workarounds needed to take care of an equivalent behavior. 
 
+The library can be used also as a workaround on compilers that doesn't provides explicit conversion operators.
+
 Note that [*Boost.Conversion] is not particularly concerned with cases of: 
 
 * type-to-type conversion via an input/output stream as Boost.LexicalCast does or 
@@ -126,7 +128,15 @@
 
 [section Motivation]
 
-When conversion is useful, but not provided by unrelated classes, the recommended approach is to use a named free function. One example of this could be a `date_to_week(date const&)` function. 
+When conversion is useful, but not provided by unrelated classes, the recommended approach is to use a named free function. One example of this could be a `date_to_week(date const&)` function. Other example are found on the standard chrono library
+
+    class system_clock {
+    public:
+      typedef chrono::time_point<system_clock>     time_point;
+      //...
+      static std::time_t to_time_t(const time_point<system_clock>& t);
+      static time_point<system_clock>  from_time_t(std::time_t t);
+  };
 
 This approach works well when the source and destination are known at compile time, but when templates are involved, it becomes problematic. How can one write generic code for user-supplied classes when the source and destination types could be anything? Predicting the name becomes impossible, `operator T()` is the accepted way to express such an intent.