[Boost-commit] svn:boost r54185 - sandbox/committee/LWG/proposals

Subject: [Boost-commit] svn:boost r54185 - sandbox/committee/LWG/proposals
From: dave_at_[hidden]
Date: 2009-06-22 03:44:48

Author: dave
Date: 2009-06-22 03:44:47 EDT (Mon, 22 Jun 2009)
New Revision: 54185
URL: http://svn.boost.org/trac/boost/changeset/54185

Log:
More Motivation

Text files modified: 
   sandbox/committee/LWG/proposals/exported-concept-maps.rst |    62 ++++++++++++++++++++++++++++++++++++--- 
   1 files changed, 56 insertions(+), 6 deletions(-)

Modified: sandbox/committee/LWG/proposals/exported-concept-maps.rst
==============================================================================
--- sandbox/committee/LWG/proposals/exported-concept-maps.rst	(original)
+++ sandbox/committee/LWG/proposals/exported-concept-maps.rst	2009-06-22 03:44:47 EDT (Mon, 22 Jun 2009)
@@ -68,12 +68,12 @@
       { ... }
   }
 
-We propose to allow ``concept_map``\ s to be explicitly “exported” to unconstrained
-contexts like this::
+We propose to allow ``concept_map``\ s to be explicitly “exported” to
+unconstrained contexts like this::
 
   export concept_map LessThanComparable<Num> { } // OK
   
-Then the unconstrained definition of ``f`` above will work as might be
+Then the unconstrained definition of ``f`` above will work as
 expected.  We also propose that concept maps generated with the
 “intentional concept mapping” syntax described in D2916=09-0106 (if it
 is accepted) be exported, so ``Num`` could be declared this way::
@@ -88,10 +88,60 @@
 ==========
 
 The status quo creates a disturbing divide between constrained and
-unconstrained code.
+unconstrained code.  Does the original definition of ``Num`` model
+``LessThanComparable``?  In constrained code, yes; in unconstrained
+code, no.  In order to make ``Num`` model ``LessThanComparable``
+everywhere, one actually needs to duplicate all the default
+definitions that have already been supplied by the template for
+constrained code::
 
-* Divide between constrained and unconstrained code.
-* Is Num LessThanComparable?  In constrained code, yes.  In unconstrained code, no.
+  class Num
+  {
+      friend bool operator<(Num const& x, Num const& y)
+      { ... }
+      // copy-paste-munge from LessThanComparable
+      friend bool operator>(Num const& x, Num const& y) { return y < x; }
+      friend bool operator<=(Num const& x, Num const& y) { return !(y < x); }
+      friend bool operator>=(Num const& x, Num const& y) { return !(x < y); }
+  };
+
+Unlike an empty concept map, whose verbosity has caused some concern,
+this boilerplate code truly adds zero value (except inasmuch as it
+provides the desired operators for unconstrained code) and carries
+with it all the usual disadvantages of duplicated code.  
+
+Default implementations of associated functions arise in concepts like
+``LessThanComparable`` whose interfaces are **non-minimal**, i.e. they
+contain elements that can be implemented entirely in terms of other
+interface elements.  In C++03 the usual way to avoid repeating this
+boilerplate in each model of a concept is to capture the redundancy in
+a base class template::
+
+  // Derive your Model from this class (that's the Curiously Recurring
+  // Template Pattern, CRTP) to implement redundant interface elements
+  template <class Model>
+  struct less_than_comparable
+  {
+      friend bool operator>(Model const& x, Model const& y) { return y < x; }
+      friend bool operator<=(Model const& x, Model const& y) { return !(y < x); }
+      friend bool operator>=(Model const& x, Model const& y) { return !(x < y); }
+  };
+  
+  struct Num : less_than_comparable<Num>
+  {
+      friend bool operator<(Num const&, Num const&);
+  };
+
+  struct String : less_than_comparable<String>
+  {
+      friend bool operator<(String const&, String const&);
+  };
+
+If this proposal is accepted, all such CRTP base classes templates
+could be discarded, the redundant interface being implemented directly
+by the concept.  The Boost.Operators library, for example, could be
+eliminated for C++0x, and the Boost.Iterator library would shrink
+substantially.
 
 Rationales
 ==========