Subject: [Boost-commit] svn:boost r83246 - sandbox/type_erasure/libs/type_erasure/doc
From: steven_at_[hidden]
Date: 2013-03-02 12:43:31
Author: steven_watanabe
Date: 2013-03-02 12:43:30 EST (Sat, 02 Mar 2013)
New Revision: 83246
URL: http://svn.boost.org/trac/boost/changeset/83246
Log:
Snip some sections.
Text files modified:
sandbox/type_erasure/libs/type_erasure/doc/type_erasure.qbk | 213 ---------------------------------------
1 files changed, 2 insertions(+), 211 deletions(-)
Modified: sandbox/type_erasure/libs/type_erasure/doc/type_erasure.qbk
==============================================================================
--- sandbox/type_erasure/libs/type_erasure/doc/type_erasure.qbk (original)
+++ sandbox/type_erasure/libs/type_erasure/doc/type_erasure.qbk 2013-03-02 12:43:30 EST (Sat, 02 Mar 2013)
@@ -415,214 +415,6 @@
[endsect]
-[section:design Design Notes]
-
-This section is purely for informational
-purposes. You don't need to read it to
-understand how to use the library. Here,
-I try to explain how the library evolved
-and why I chose the current interfaces.
-
-[section:concepts Concept Interfaces]
-
-When designing the concept system, I had a couple
-of goals. First of all, the basic definitions
-need to be simple. Second, concepts need to be
-composable. Making concepts composable is fairly
-easy by recursively expanding mpl sequences.
-The first goal is much harder. In earlier
-versions of TypeErasure and in most similar libraries
-such as DynamicAny and Adobe::Poly, the base
-definitions generally resemble the following
-
- struct incrementable_interface {
- virtual void increment() = 0;
- };
- template<class T>
- struct incrementable_implementation : incrementable_interface {
- virtual void increment() { ++x; }
- T x;
- };
-
- template<class Derived>
- struct incrementable_mixin {
- Derived& operater++();
- };
-
-Note that we require three definitions, the
-virtual interface, the virtual implementation,
-and the user level interface. In the immediate
-predecessor of this library, the first two
-were combined into a single template
-
- template<class T>
- struct incrementable :
- primitive_concept<incrementable<T>, void(T&) > {
- static void apply(T& t) { ++t; }
- };
-
-Here, the `primitive_concept` base specifies the
-function signature, serving the purpose of the
-virtual interface. We now have only one class
-here, but it's still excessively complicated.
-To get rid of this we can note that the signature
-must be `remove_pointer<decltype(&incrementable<T>::apply)>::type`
-and can therefore be deduced automatically.
-
-[endsect]
-
-[section:constructors Constructors]
-
-The constructors of __any have to serve three
-different purposes. First, we have constructors
-that capture the type passed. This is what
-happens when constructing an __any from an
-`int` for example. The second kind of constructor
-dispatches to a constructor of the contained
-type using an existing set of bindings. This
-is what happens for the copy constructor. The
-last kind of constructor "upcasts" from one
-concept to another more general
-concept. For example, `any< mpl::vector<copy_constructible<>, incrementable<> > >`
-should be convertible to `any<copy_constructible<> >`.
-We want to define these three kinds of constructors
-in an unambiguous way. For short, we'll refer
-to these three kinds of constructors an binding
-constructors, dispatched constructors, and
-converting constructors.
-
-# binding constructors take an argument
- which is the object to capture and
- an optional argument specifying any
- bindings that can't be deduced.
-# dispatched constructors take the
- arguments of the underlying constructor
- and an optional argument specifing
- the bindings to use. (This extra
- argument is needed when the bindings
- can't be deduced because none of
- the arguments is an any.)
-# converting constructors take an
- argument which must be an __any
- and an optional argument indicating
- how placeholders should be substituted.
-
-Now, where are the ambiguities?
-
-* A single argument which is not an __any
- can only match a binding constructor.
- It cannot match a dispatching constructor
- because we don't have anything to dispatch on.
- It can't match a converting constructor
- because it isn't an __any.
-* A single argument which is an __any can
- match all three. We'll rule out binding
- constructors by arbitrarily deciding that
- an __any can never contain another __any.
- This makes our job a lot easier. This
- leaves us with dispatched constructors
- vs. converting constructors. If the
- Concept of the argument is different
- from the Concept of the type being
- constructed, we have to have a converting
- constructor. If the concepts are the
- same and the placeholders are the same,
- then we have the copy constructor, and
- there is no difference between the
- dispatched constructor and the converting
- constructor. If the placeholders are
- different, then we call the dispatched
- constructor. In theory it's possible
- that this is intended to be converting constructor,
- but this is rare.
-* For two arguments, the converting and binding
- constructors take one argument that is either
- a __binding or a __static_binding. They
- can be distinguised by whether the other
- argument is an __any or not.
-
-We'll add one more requirement to avoid
-going crazy. No argument of a constructor
-to __any shall be __binding or __static_binding,
-except for the ones that are explicitly
-allowed.
-
-Now, we can at least allow users to explicily
-avoid any ambiguity with the following rules.
-
-# If there are exactly two arguments and the
- first argument is neither an __any nor a specialization
- of __binding or __static_binding, and the second
- argement is a specialization of __binding
- or __static_binding, then this is a binding
- constructor.
-# If the first argument is a specialization
- of __binding, then this is a dispatching
- constructor.
-# If there are exactly two arguments and the
- first argument is an __any and the second
- argument is a specialization of __binding
- or __static_binding, the constructor is
- a converting constructor.
-
-These are not ambiguous and any constructor
-call can be converted to one of these forms.
-Note in particular that the order of the
-arguments is important. If the *first*
-argument is a __binding, then we have a
-dispatched constructor. If the *second*
-argument is a __binding or a __static_binding,
-then we have either a binding constructor or
-a converting constructor.
-
-[endsect]
-
-[section:binding Binding]
-
-The easiest implementation of manual type erasure
-uses virtual functions. However, virtual functions
-are somewhat limited. We get a lot more flexibility
-by using explicit tables of function pointers.
-
-* A table can be constructed dynamically. This
- allows us to implement conversions by creating
- a subset of the table.
-* A table is easy to share between multiple types.
- This makes it easier to implement multi-type concepts
- and __any references.
-* A table can be passed around without a corresponding
- object. This allows us to implement captured constructor
- calls that don't take an __any argument.
-
-[endsect]
-
-[endsect]
-
-[section:feedback Feedback Wanted]
-
-There are a number of things that I'm not entirely
-happy about. Any thoughts about them would be
-greatly appreciated.
-
-* The name `_self`. Basically, I need some placeholder
- to act as a default. Since placeholders act as a
- substitute for template parameters, I'd really like
- to use `_T`. Alack-a-day, `_T` is a reserved identifier.
- `_self` was the best I could think of.
-* __relaxed_match. I considered a lot of names
- for this, `strict_match<false>`, `enable_mixed`,
- `nonstrict_match`, `loose_match`, `best_effort`,
- and probably more that I've forgotten. I'm not
- really happy with any of them. I'm not really
- happy about having it in `Concept` either, but
- I'm not sure where else it could go. It's presence
- can affect the contents of the vtable, so if it
- were a separate template argument, it would have
- to be passed to __binding as well. It would generally
- add complication.
-
-[endsect]
-
[section:future Future Work]
These are just some ideas. There is absolutely no
@@ -631,9 +423,8 @@
* Use SBO.
* Allow more control over vtable layout.
* Attempt to reuse sub-tables in conversions.
-* Allow "dynamic_cast".
-* Use C++0x features. (Rvalue references and
- variadic templates in particular.)
+* Allow "dynamic_cast". This requires creating
+ a global registry of concept mappings.
* Optimize the compile-time cost.
[endsect]