From 0b5a383cb200844a2adb77114c3cc11fbb36b37f Mon Sep 17 00:00:00 2001
From: nobody
Date: Thu, 8 Apr 2004 01:30:33 +0000
Subject: [PATCH] This commit was manufactured by cvs2svn to create branch
'expaler'.
[SVN r2110]
---
doc/Jamfile.v2 | 6 -
doc/enable_if.html | 417 -----------------
doc/lexicographic.html | 302 -------------
doc/named_params.html | 444 ------------------
doc/named_params.rst | 427 ------------------
doc/tribool.boostbook | 167 -------
include/boost/ref.hpp | 249 ----------
include/boost/utility/enable_if.hpp | 87 ----
include/boost/utility/lexicographic.hpp | 105 -----
include/boost/utility/select_by_size.hpp | 175 -------
include/boost/utility/type_deduction.hpp | 476 --------------------
ref_call_test.cpp | 158 -------
result_of_test.cpp | 35 --
select_by_size.html | 232 ----------
select_by_size_test.cpp | 60 ---
test/Jamfile | 23 -
test/enable_if_LICENSE | 23 -
test/enable_if_constructors.cpp | 60 ---
test/enable_if_dummy_arg_disambiguation.cpp | 44 --
test/enable_if_lazy.cpp | 80 ----
test/enable_if_lazy_test.cpp | 98 ----
test/enable_if_member_templates.cpp | 41 --
test/enable_if_namespace_disambiguation.cpp | 45 --
test/enable_if_no_disambiguation.cpp | 41 --
test/enable_if_partial_specializations.cpp | 65 ---
test/lex_performance_test.cpp | 135 ------
test/lexicographic_test.cpp | 74 ---
test/named_params_sfinae.cpp | 79 ----
test/named_params_test.cpp | 156 -------
test/tribool_rename_test.cpp | 129 ------
test/tribool_test.cpp | 127 ------
type_deduction_tests.cpp | 343 --------------
32 files changed, 4903 deletions(-)
delete mode 100644 doc/Jamfile.v2
delete mode 100644 doc/enable_if.html
delete mode 100644 doc/lexicographic.html
delete mode 100755 doc/named_params.html
delete mode 100755 doc/named_params.rst
delete mode 100644 doc/tribool.boostbook
delete mode 100644 include/boost/ref.hpp
delete mode 100644 include/boost/utility/enable_if.hpp
delete mode 100644 include/boost/utility/lexicographic.hpp
delete mode 100644 include/boost/utility/select_by_size.hpp
delete mode 100644 include/boost/utility/type_deduction.hpp
delete mode 100644 ref_call_test.cpp
delete mode 100644 result_of_test.cpp
delete mode 100644 select_by_size.html
delete mode 100644 select_by_size_test.cpp
delete mode 100644 test/Jamfile
delete mode 100644 test/enable_if_LICENSE
delete mode 100644 test/enable_if_constructors.cpp
delete mode 100644 test/enable_if_dummy_arg_disambiguation.cpp
delete mode 100644 test/enable_if_lazy.cpp
delete mode 100644 test/enable_if_lazy_test.cpp
delete mode 100644 test/enable_if_member_templates.cpp
delete mode 100644 test/enable_if_namespace_disambiguation.cpp
delete mode 100644 test/enable_if_no_disambiguation.cpp
delete mode 100644 test/enable_if_partial_specializations.cpp
delete mode 100644 test/lex_performance_test.cpp
delete mode 100644 test/lexicographic_test.cpp
delete mode 100755 test/named_params_sfinae.cpp
delete mode 100755 test/named_params_test.cpp
delete mode 100644 test/tribool_rename_test.cpp
delete mode 100644 test/tribool_test.cpp
delete mode 100644 type_deduction_tests.cpp
diff --git a/doc/Jamfile.v2 b/doc/Jamfile.v2
deleted file mode 100644
index 354831c..0000000
--- a/doc/Jamfile.v2
+++ /dev/null
@@ -1,6 +0,0 @@
-project boost-sandbox/utility/doc ;
-import boostbook ;
-import doxygen ;
-
-doxygen reference : ../../../boost/tribool.hpp : boost ;
-boostbook tribool : tribool.boostbook ;
diff --git a/doc/enable_if.html b/doc/enable_if.html
deleted file mode 100644
index 349189e..0000000
--- a/doc/enable_if.html
+++ /dev/null
@@ -1,417 +0,0 @@
-
-
-enable_if
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- enable_if
-
-
-Copyright 2003 Jaakko Järvi, Jeremiah Willcock, Andrew Lumsdaine.
-
-
-
-1 Introduction
-
-
-The enable_if family of templates is a set of tools to allow a function template or a class template specialization
-to include or exclude itself from a set of matching functions or specializations
-based on properties of its template arguments.
-For example, one can define function templates that
-are only enabled for, and thus only match, an arbitrary set of types
-defined by a traits class. The enable_if templates can also be
-applied to enable class template specializations. Applications of
-enable_if are discussed in length
-in [1 ] and [2 ].
-
-
-
-1.1 Synopsis
-
-
-
-namespace boost {
- template <class Cond, class T = void> struct enable_if;
- template <class Cond, class T = void> struct disable_if;
- template <class Cond, class T> struct lazy_enable_if;
- template <class Cond, class T> struct lazy_disable_if;
-
- template <bool B, class T = void> struct enable_if_c;
- template <bool B, class T = void> struct disable_if_c;
- template <bool B, class T> struct lazy_enable_if_c;
- template <bool B, class T> struct lazy_disable_if_c;
-}
-
-
-
-1.2 Background
-
-
-Sensible operation of template function overloading in C++ relies
-on the SFINAE (substitution-failure-is-not-an-error)
-principle [3 ]: if an invalid argument
-or return type is formed during the instantiation of a function
-template, the instantiation is removed from the overload resolution
-set instead of causing a compilation error. The following example,
-taken from [1 ],
-demonstrates why this is important:
-
-
-int negate(int i) { return -i; }
-
-template <class F>
-typename F::result_type negate(const F& f) { return -f(); }
-
-
-Suppose the compiler encounters the call negate(1) . The first
-definition is obviously a better match, but the compiler must
-nevertheless consider (and instantiate the prototypes) of both
-definitions to find this out. Instantiating the latter definition with
-F as int would result in:
-
-
-int::result_type negate(const int&);
-
-
-where the return type is invalid. If this was an error, adding an unrelated function template
-(that was never called) could break otherwise valid code.
-Due to the SFINAE principle the above example is not, however, erroneous.
-The latter definition of negate is simply removed from the overload resolution set.
-
-The enable_if templates are tools for controlled creation of the SFINAE
-conditions.
-
-
-
-2 The enable_if templates
-
-
-The names of the enable_if templates have three parts: an optional lazy_ tag,
-either enable_if or disable_if , and an optional _c tag.
-All eight combinations of these parts are supported.
-The meaning of the lazy_ tag is described in Section 3.3 .
-The second part of the name indicates whether a true condition argument should
-enable or disable the current overload.
-The third part of the name indicates whether the condition argument is a bool value
-(_c suffix), or a type containing a static bool constant named value (no suffix).
-The latter version interoperates with Boost.MPL.
-
-The definitions of enable_if_c and enable_if are as follows (we use enable_if templates
-unqualified but they are in the boost namespace).
-
-
-template <bool B, class T = void>
-struct enable_if_c {
- typedef T type;
-};
-
-template <class T>
-struct enable_if_c<false, T> {};
-
-template <class Cond, class T = void>
-struct enable_if : public enable_if_c<Cond::value, T> {};
-
-
-An instantiation of the enable_if_c template with the parameter
-B as true contains a member type type , defined
-to be T . If B is
-false , no such member is defined. Thus
-enable_if_c<B, T>::type is either a valid or an invalid type
-expression, depending on the value of B .
-When valid, enable_if_c<B, T>::type equals T .
-The enable_if_c template can thus be used for controlling when functions are considered for
-overload resolution and when they are not.
-For example, the following function is defined for all arithmetic types (according to the
-classification of the Boost type_traits library ):
-
-
-template <class T>
-typename enable_if_c<boost::is_arithmetic<T>::value, T>::type
-foo(T t) { return t; }
-
-
-The disable_if_c template is provided as well, and has the
-same functionality as enable_if_c except for the negated condition. The following
-function is enabled for all non-arithmetic types.
-
-
-template <class T>
-typename disable_if_c<boost::is_arithmetic<T>::value, T>::type
-bar(T t) { return t; }
-
-
-For easier syntax in some cases and interoperation with Boost.MPL we provide versions of
-the enable_if templates taking any type with a bool member constant named
-value as the condition argument.
-The MPL bool_ , and_ , or_ , and not_ templates are likely to be
-useful for creating such types. Also, the traits classes in the Boost.Type_traits library
-follow this convention.
-For example, the above example function foo can be alternatively written as:
-
-
-template <class T>
-typename enable_if<boost::is_arithmetic<T>, T>::type
-foo(T t) { return t; }
-
-
-
-
-3 Using enable_if
-
-
-The enable_if templates are defined in
-boost/utility/enable_if.hpp , which is included by boost/utility.hpp .
-
-The enable_if template can be used either as the return type, or as an
-extra argument. For example, the foo function in the previous section could also be written
-as:
-
-
-template <class T>
-T foo(T t, typename enable_if<boost::is_arithmetic<T> >::type* dummy = 0);
-
- Hence, an extra parameter of type void* is added, but it is given
-a default value to keep the parameter hidden from client code.
-Note that the second template argument was not given to enable_if , as the default
-void gives the desired behavior.
-
-Whether to write the enabler as an argument or within the return type is
-largely a matter of taste, but for certain functions, only one
-alternative is possible:
-
-Operators have a fixed number of arguments, thus enable_if must be used in the return type.
- Constructors and destructors do not have a return type; an extra argument is the only option.
- There does not seem to be a way to specify an enabler for a conversion operator. Converting constructors,
-however, can have enablers as extra default arguments.
-
-
-
-3.1 Enabling template class specializations
-
-
-Class template specializations can be enabled or disabled with enable_if .
-One extra template parameter needs to be added for the enabler expressions.
-This parameter has the default value void .
-For example:
-
-
-template <class T, class Enable = void>
-class A { ... };
-
-template <class T>
-class A<T, typename enable_if<is_integral<T> >::type> { ... };
-
-template <class T>
-class A<T, typename enable_if<is_float<T> >::type> { ... };
-
- Instantiating A with any integral type matches the first specialization,
-whereas any floating point type matches the second one. All other types
-match the primary template.
-The condition can be any compile-time boolean expression that depends on the
-template arguments of the class.
-Note that again, the second argument to enable_if is not needed; the default (void )
-is the correct value.
-
-
-
-3.2 Overlapping enabler conditions
-
-
-Once the compiler has examined the enabling conditions and included the
-function into the overload resolution set, normal C++ overload resolution
-rules are used to select the best matching function.
-In particular, there is no ordering between enabling conditions.
-Function templates with enabling conditions that are not mutually exclusive can
-lead to ambiguities. For example:
-
-
-template <class T>
-typename enable_if<boost::is_integral<T>, void>::type
-foo(T t) {}
-
-template <class T>
-typename enable_if<boost::is_arithmetic<T>, void>::type
-foo(T t) {}
-
-
-All integral types are also arithmetic. Therefore, say, for the call foo(1) ,
-both conditions are true and both functions are thus in the overload resolution set.
-They are both equally good matches and thus ambiguous.
-Of course, more than one enabling condition can be simultaneously true as long as
-other arguments disambiguate the functions.
-
-The above discussion applies to using enable_if in class template
-partial specializations as well.
-
-
-
-3.3 Lazy enable_if
-
-
-In some cases it is necessary to avoid instantiating part of a
-function signature unless an enabling condition is true. For example:
-
-
-template <class T, class U> class mult_traits;
-
-template <class T, class U>
-typename enable_if<is_multipliable<T, U>, typename mult_traits<T, U>::type>::type
-operator*(const T& t, const U& u) { ... }
-
- Assume the class template mult_traits is a traits class defining
-the resulting type of a multiplication operator. The is_multipliable traits
-class specifies for which types to enable the operator. Whenever
-is_multipliable<A, B>::value is true for some types A and B ,
-then mult_traits<A, B>::type is defined.
-
-Now, trying to invoke (some other overload) of operator* with, say, operand types C and D
-for which is_multipliable<C, D>::value is false
-and mult_traits<C, D>::type is not defined is an error on some compilers.
-The SFINAE principle is not applied because
-the invalid type occurs as an argument to another template. The lazy_enable_if
-and lazy_disable_if templates (and their _c versions) can be used in such
-situations:
-
-
-template<class T, class U>
-typename lazy_enable_if<is_multipliable<T, U>, mult_traits<T, U> >::type
-operator*(const T& t, const U& u) { ... }
-
- The second argument of lazy_enable_if must be a class type
-that defines a nested type named type whenever the first
-parameter (the condition) is true.
-
-
-
-Note
-
-Referring to one member type or static constant in a traits class
-causes all of the members (type and static constant) of that
-specialization to be instantiated. Therefore, if your traits classes
-can sometimes contain invalid types, you should use two distinct
-templates for describing the conditions and the type mappings. In the
-above example, is_multipliable<T, U>::value defines when
-mult_traits<T, U>::type is valid.
-
-
-
-3.4 Compiler workarounds
-
-
-Some compilers flag functions as ambiguous if the only distinguishing factor is a different
-condition in an enabler (even though the functions could never be ambiguous). For example,
-some compilers (e.g. GCC 3.2) diagnose the following two functions as ambiguous:
-
-
-template <class T>
-typename enable_if<boost::is_arithmetic<T>, T>::type
-foo(T t);
-
-template <class T>
-typename disable_if<boost::is_arithmetic<T>, T>::type
-foo(T t);
-
- Two workarounds can be applied:
-
-Use an extra dummy parameter which disambiguates the functions. Use a default value for
-it to hide the parameter from the caller. For example:
-
-
-template <class T> struct dummy { dummy(int) {} };
-
-template <class T>
-typename enable_if<boost::is_arithmetic<T>, T>::type
-foo(T t, dummy<0> = 0);
-
-template <class T>
-typename disable_if<boost::is_arithmetic<T>, T>::type
-foo(T t, dummy<1> = 0);
-
-
- Define the functions in different namespaces and bring them into a common
-namespace with using declarations:
-
-
-namespace A {
- template <class T>
- typename enable_if<boost::is_arithmetic<T>, T>::type
- foo(T t);
-}
-
-namespace B {
- template <class T>
- typename disable_if<boost::is_arithmetic<T>, T>::type
- foo(T t);
-}
-
-using A::foo;
-using B::foo;
-
-
-Note that the second workaround above cannot be used for member
-templates. On the other hand, operators do not accept extra arguments,
-which makes the first workaround unusable. As the net effect,
-neither of the workarounds are of assistance for templated operators that
-need to be defined as member functions (assignment and
-subscript operators).
-
-
-
-4 Acknowledgements
-
-We are grateful to Howard Hinnant, Jason Shirk, Paul Mensonides, and Richard
-Smith whose findings have influenced the library.
-
-
-
-References
-[1]
-Jaakko Järvi, Jeremiah Willcock, Howard Hinnant, and Andrew Lumsdaine.
-Function overloading based on arbitrary properties of types.
-C/C++ Users Journal , 21(6):25--32, June 2003.
-
- [2]
-Jaakko Järvi, Jeremiah Willcock, and Andrew Lumsdaine.
-Concept-controlled polymorphism.
-In Frank Pfennig and Yannis Smaragdakis, editors, Generative
- Programming and Component Engineering , volume 2830 of LNCS , pages
- 228--244. Springer Verlag, September 2003.
-
- [3]
-David Vandevoorde and Nicolai M. Josuttis.
-C++ Templates: The Complete Guide .
-Addison-Wesley, 2002.
-
-
-
-
-
-
-
-Contributed by:
-Jaakko Järvi, Jeremiah Willcock and Andrew Lumsdaine
-{jajarvi|jewillco|lums}@osl.iu.edu
-Indiana University
-Open Systems Lab
-
-
-
-
-This document was translated from LA TE X by
- HE VE A .
-
-
-
diff --git a/doc/lexicographic.html b/doc/lexicographic.html
deleted file mode 100644
index bcf577d..0000000
--- a/doc/lexicographic.html
+++ /dev/null
@@ -1,302 +0,0 @@
-
-
-
-
-
-
- Boost.Utility - lexicographic documentation
-
-
-
-
-
- Utility - Lexicographic
-
-
-
- The class boost::lexicographic
provides an easy way
- to avoid complex and errorprone if-else cascades to do lexicographic
- comparisions on certain different criteria. The class is in the header
- boost/utility/lexicographic.hpp and depends on no others headers.
- The test code is in
- lexicographic_test.cpp .
-
-
- Contents
-
-
-
-
- Often one has to write comparisions which give an ordering between
- various kinds of data. When they look in a certain
- specified order at one relation between two data items at a time and
- result in a lexicographic comparision of all these relations the
- programmer often has to write long if-else cascades. These cascades
- are often complex and difficult to maintain. The class
- boost::lexicographic
helps in this scenario. Its constructor
- and function call operator takes two data items which need to be
- compared as arguments and performs to comparision. The order in which
- the function call operators are called determine the lexicographic order
- of the relations. Since the result of all further comparisions might not
- be needed after a certain step, they are not executed.
- The logic of the class assumes an ascending order as implied by the
- operator <
. If a descending order needs to be obtained
- one can just switch the order of the arguments. Additionally, both the
- constructor and the function call operator provide also a three argument
- form which takes a functor for comparisions as a third argument.
-
-
- Relation to std::lexicographic_compare
-
- The standard C++ algorithm std::lexicographic_compare
- does essentially the same thing but in a different situation. It compares
- sequences of data items of equal type. Whereas boost::lexicographic
- compares individual data items of different type, and every comparison
- must be specified explicitly by using the function call operator of the class.
-
-
- Relation to if-else-cascades
-
- Advantages
-
- The order of comparisons can easily be changed.
- Single comparisons can be added or removed in one line.
- Comparisons can be split up to be computed partly in one
- function and partly in another by using
- boost::lexicographic
as a functor.
- It documents the code in a better fashion and expresses
- the users intention directly.
- If the comparison arguments do not need computation, there is in
- theory no performance overhead.
-
- Disadvantages
-
- There is no short-circuiting. All arguments will be
- evaluated, also if
- an earlier comparison step already gave the final result. As long as the
- arguments are trivial there should be no performance overhead. The only
- way to avoid evaluation of arguments is to place every comparison step
- in an if-statement like:
-
-boost::lexicographic cmp (complex_computation (a), complex_computation (b));
-if (cmp.result () == lexicographic::equivalent)
-{
- cmp (complex_computation (c), complex_computation (d));
- if (cmp.result () == lexicographic::equivalent)
- {
- cmp (complex_computation (e), complex_computation (f));
- }
-}
-// do something with cmp
-
-
- But this construct eats up many of the advantages of using
- boost::lexicographic
.
-
- The performance of using boost::lexicographic
, besides
- the lack of short-circuiting, is not negligible.
- Tests with gcc 3.2.2 showed, that the algorithmic overhead
- is about 40% in comparison to according to if-else-cascades.
- Additionally gcc failed to inline everything properly, so that the
- resulting performance overhead was about a factor two.
-
-
-
-
-
- An example usage are special sorting operators, such as the lexicographic
- ordering of tuples:
-
-struct position
-{
- double x, y, z;
-};
-
-bool operator < (position const &p1, position const &p2)
-{
- return boost::lexicographic (p1.x, p2.x)
- (p1.y, p2.y)
- (p1.z, p2.z);
-}
-
- An alternative form of writing this without boost::lexicographic
- would be this:
-
-bool operator < (position const &p1, position const &p2)
-{
- if (p1.x == p2.x)
- if (p1.y == p2.y)
- return p1.z < p2.z;
- else
- return p1.y < p2.y;
- else
- return p1.x < p2.x;
-}
-
- It is also easy to use different functor such as a case insensitive
- comparision function object in the next example.
-
-struct person
-{
- std::string firstname, lastname;
-};
-
-bool operator < (person const &p1, person const &p2)
-{
- return boost::lexicographic
- (p1.lastname, p2.lastname, cmp_case_insensitive)
- (p1.firstname, p2.firstname, cmp_case_insensitive);
-}
-
-
-
-
-
-namespace boost
-{
-
- class lexicographic
- {
- public:
- enum result_type { minus = -1, equivalent, plus };
-
- template <typename T1, typename T2>
- lexicographic (T1 const &a, T2 const &b);
-
- template <typename T1, typename T2, typename Cmp>
- lexicographic (T1 const &a, T2 const &b, Cmp cmp);
-
- template <typename T1, typename T2>
- lexicographic &operator () (T1 const &a, T2 const &b);
-
- template <typename T1, typename T2, typename Cmp>
- lexicographic &operator () (T1 const &a, T2 const &b, Cmp cmp);
-
- result_type result () const;
- operator unspecified_bool_type () const;
- };
-
- bool operator == (lexicographic l1, lexicographic l2);
- bool operator != (lexicographic l1, lexicographic l2);
-
-}
-
-
-
- result_type
- enum result_type { minus = -1, equivalent = 0, plus = +1 };
-
- Defines the result type of the class. It is kept as internal state
- and is returned by result ()
.
- The integer representation of it is equivalent to the one
- returned by std::strcmp
.
-
- minus
- the sequence of the first arguments
- of constructor and function call operators
- is lexicographically less than the according
- sequence of the second arguments.
- equivalent
- all elements of the sequences
- of the first and the second arguments are identical.
- plus
- the sequence of the first arguments
- of constructor and function call operators
- is lexicographically greater than the according
- sequence of the second arguments.
-
-
-
- constructors
- template <typename T1, typename T2>
- lexicographic (T1 const &a, T2 const &b);
-
- Constructs new object and does the first comparision
- step between a
and b
. It uses
- operator <
for comparisions.
-
-
- template <typename T1, typename T2, typename Cmp>
- lexicographic (T1 const &a, T2 const &b, Cmp cmp);
-
- Constructs new object and does the first comparision
- step between a
and b
. It uses
- cmp
for comparisions.
-
-
- function call operators
- template <typename T1, typename T2>
- lexicographic &operator () (T1 const &a, T2 const &b);
-
- Does next comparision step on object between a
- and b
. It uses operator <
for
- comparisions.
-
-
- template <typename T1, typename T2, typename Cmp>
- lexicographic &operator () (T1 const &a, T2 const &b, Cmp cmp);
-
- Does next comparision step on object between a
- and b
. It uses cmp
for
- comparisions.
-
-
- result
- result_type result () const;
-
- Gives result of already done comparision steps.
-
-
- conversions
- operator unspecified_bool_type () const;
-
- This conversion operator allows objects to be used in boolean
- contexts, like if (lexicographic (a, b)) {}
. The
- actual target type is typically a pointer to a member function,
- avoiding many of the implicit conversion pitfalls.
- It evaluates to true
if result () == minus
,
- otherwise to false
.
-
-
-
- comparision
- bool operator == (lexicographic l1, lexicographic l2);
-
- Returns l1.result () == l2.result ()
.
- That means it returns true
if both
- objects are in the same state.
-
-
- bool operator != (lexicographic l1, lexicographic l2);
-
- Returns l1.result () != l2.result ()
.
- That means it returns true
if the two
- objects are in the a different state.
-
-
-
-
- The author of boost::lexicographic
is Jan Langer (jan@langernetz.de).
- Ideas and suggestions from Steve Cleary, David Abrahams, Gennaro Proata, Paul Bristow, Daniel Frey, Daryle Walker and Brian McNamara were used.
-
-
-
- October 5, 2003
-
- © Copyright Jan Langer 2003
- Use, modification, and distribution is subject to the Boost Software
- License, Version 1.0. (See accompanying file
- LICENSE_1_0.txt or copy at
- www.boost.org/LICENSE_1_0.txt )
-
-
-
diff --git a/doc/named_params.html b/doc/named_params.html
deleted file mode 100755
index 4b3723f..0000000
--- a/doc/named_params.html
+++ /dev/null
@@ -1,444 +0,0 @@
-
-
-
-
-
-
-The Boost.NamedParams Library Boost
-
-
-
-
-
The Boost.NamedParams Library
-
-
-
-
-
-
In C++ function arguments are given meaning by their position in
-the parameter list. This protocol is fine when there are few
-parameters with default values, but as the number of parameters
-grows, so does the inconvenience of passing arguments in the
-correct order, especially in the presence of default values:
-
-
-It can become difficult for readers to understand the meaning of
-arguments at the call site:
-
-window* w = new_window("alert", true, true, false, 77, 65);
-
-
-Since meaning is given by position, we have to choose some
-(often arbitrary) order for parameters with default values,
-making some combinations of defaults unusable:
-
-window* new_window(
- char const* name, bool border = true
- , bool opaque = true, bool movable = false
- , int width = 100, int height = 100);
-
-const bool movability = true;
-window* w = new_window("alert2", movability); // error!
-
-
-Default values can not depend on the values of other function
-parameters:
-
-window* new_window(
- char const* name, bool border, ...
- , int width = 100, int heigh = width); // error!
-
-
-Template types can not be deduced from the default values, so
-we have to resort to overloading to provide default values for
-parameters with template type:
-
-template<class T> void f(T x = 0);
-
-f(); // error!
-
-
-
-
-
This library is an attempt to address the problems outlined above
-by associating each parameter with a keyword identifier. Using
-this library, users can identify parameters by name instead of just
-argument position:
-
-window* w = new_window("alert2", movable = movability); // OK!
-
-
-
-
-
-
-
This example shows how to wrap a function:
-
-void foo(char const* name, float value);
-
-
to give both parameters names and default values.
-
-
-
First we define the named parameter keywords. This is done by creating
-"tag" types for each keyword, and declaring keyword< tag > objects:
-
-#include <boost/named_params.hpp>
-
-struct name_t; // tag types
-struct value_t;
-
-namespace {
- boost::keyword<name_t> name; // keyword objects
- boost::keyword<value_t> value;
-}
-
-
Placing these keyword objects in an unnamed namespace will prevent
-link errors when you declare keywords in header files [Note :
-the tag types should generally not be declared in an unnamed
-namespace]. We also need to create a keywords list for our
-function. These keywords should be declared in the same order as
-their corresponding parameters appear in the function's parameter
-list:
-
-struct foo_keywords
- : boost::keywords<
- name_t
- , value_t
- >
-{};
-
-
-
-
-
-template<class Params>
-void foo_impl(const Params&);
-
-void foo()
-{
- foo_impl(foo_keywords());
-}
-
-template<class A0>
-void foo(const A0& a0)
-{
- foo_impl(foo_keywords(a0));
-}
-
-template<class A0, class A1>
-void foo(const A0& a0, const A1& a1)
-{
- foo_impl(foo_keywords(a0, a1));
-}
-
-
-
-
-
-template<class Params>
-void foo_impl(const Params& params)
-{
- std::cout << params[name] << " = " << params[value] << "\n";
-}
-
-
That's it. The user calls the foo() forwarding functions, with
-either positional or named parameters. For instance:
-
-foo("bar", 3.14f);
-foo(value = 6.28f, "baz")
-
-
Should print:
-
-bar = 3.14
-baz = 6.28
-
-
But we still don't have any default values, leaving any of the
-parameters out results in a compilation error:
-
-foo()
-foo("bar")
-foo(value = 3)
-
-
All fails.
-
Fortunatly, adding default values to parameters is easy:
-
-template<class Params>
-void foo_impl(const Params& params)
-{
- std::cout
- << params[name | "unnamed"] << " = "
- << params[value | 0] << "\n";
-}
-
-
We are using operator| to denote the default value of a named
-parameter.
-
Going back a little to the foo() call that didn't compile:
-
-foo()
-foo("bar")
-foo(value = 3)
-
-
Now compiles, and prints:
-
-unnamed = 0
-bar = 0
-unnamed = 3
-
-
-
-
-
-
Because the keywords' operator= returns a temporary, and
-temporaries cannot be bound to non-const reference parameters,
-our forwarding functions need to take their arguments by const
-reference . As a result, an argument which is bound
-to a keyword with operator= can be transparently passed by
-non-const reference, but positional arguments are always passed by
-const reference unless we use the Boost.Ref library to
-indicate otherwise:
-
-#include <boost/ref.hpp>
-
-float x;
-foo(value = x); // held type is float&
-foo(x); // held type is float const&, need help!
-foo(boost::ref(x)); // held type is float&
-
-
Instances of boost::reference_wrapper<> generated by
-boost::ref will be unwrapped automatically by the library.
-
-
-
-
The parameters of our templated forwarding functions are completely
-general; in fact, they're a perfect match for any argument type
-whatsoever. The problems with exposing such general function
-templates have been the subject of much discussion; especially in
-the presence of unqualified calls . Probably the safest thing
-to do is to isolate the forwarding functions in a namespace
-containing no types , but often we'd like our functions
-to play nicely with argument-dependent lookup and other function
-overloads. In that case, it's neccessary to somehow remove the
-functions from the overload set when the passed argument types
-don't meet their needs.
-
This sort of overload control can be accomplished in C++ by taking
-advantage of SFINAE (Substitution Failure Is Not An Error). If
-type substitution during the instantiation of a function template
-results in an invalid type, no compilation error is emitted;
-instead the overload is removed from the overload set. By producing
-an invalid type in the function signature depending on the result
-of some condition, whether or not an overload is considered during
-overload resolution can be controlled. The technique is formalized
-in the enable_if utility.
-
The named parameters library provides built-in SFINAE support
-through the following class template:
-
-template<
- class KeywordTag
- , class HasDefaultValue // mpl::true_ or mpl::false_
- , class Predicate
->
-struct named_param;
-
-
The key parameter, Predicate shall be a unary MPL lambda
-expression or Metafunction Class that, when applied to the
-actual type the argument, indicates whether that argument type
-meets the function's requirements for that parameter position.
-
For example, let's say we want to restrict our foo() so that
-the name parameter must be convertible to const char* .
-We'll replace our use of the name_t tag with a specialization
-of boost::named_param :
-
-struct foo_keywords
- : boost::keywords<
- boost::named_param<
- name_t
- , mpl::false_
- , is_convertible<mpl::_, const char*>
- >
- , value_t
- >
-{};
-
-
Now we can add an additional optional argument to each of our
-foo overloads
-
-template<class A0>
-void foo(
- const A0& a0
- , foo_keywords::restrict<A0>::type x = foo_keywords()
-)
-{
- foo_impl(x(a0));
-}
-
-template<class A0, class A1>
-void foo(
- const A0& a0, const A1& a1
- , foo_keywords::restrict<A0,A1>::type x = foo_keywords()
-)
-{
- foo_impl(x(a0, a1));
-}
-
-
These additional parameters are not intended to be used directly
-by callers; they merely trigger SFINAE by becoming illegal types
-when the name argument is not convertible to const char* .
-
-
-
-
If computing an argument's default value is expensive, it's best
-avoided when the argument is supplied by the user. In that case,
-the default value can be lazily evaluated using the following
-syntax:
-
-params[keyword || nullary_function ];
-
-
nullary_function must be a function object that is callable
-without arguments, and that indicates its return type via a nested
-result_type . Boost.Bind can be used to produce an appropriate
-function object from a regular function pointer:
-
-// expensive default computation function
-float default_span(float x, float theta);
-
-// implementation of bar()
-template <class Params>
-void bar_impl(Params const& params)
-{
- // Extract arguments
- float x_ = params[x];
- float theta_ = params[theta | pi];
- float span = params[span || boost::bind(default_span, x_, theta_)];
- ...
-}
-
-
-
-
-
To reduce the work needed to write functions with named parameters,
-we supply a macro that generates the boilerplate code.
-
Synopsis:
-
-BOOST_NAMED_PARAMS_FUN(
- return_type, function_name
- , min_arity, max_arity, keywords_type
-);
-
-
To generate all the forwarding functions and the implementation
-function for our example, we need only apply
-BOOST_NAMED_PARAMS_FUN this way:
-
-BOOST_NAMED_PARAMS_FUN(void, foo, 0, 2, foo_keywords)
-{
- std::cout
- << p[name | "unnamed"] << " = "
- << p[value | 0] << "\n";
-}
-
-
-
-
-
Boost.NamedParams has been confirmed to work on the following compilers:
-
-
-Microsoft VC6 sp5, VC7
-Microsoft VC7.1
-GCC3.3.1 (cygwin), GCC2.95.3 (cygwin), GCC3.2 (mingw)
-Metrowerks Codewarrior Pro8 and Pro9 (Windows)
-Intel C++ 5.0,6.0,7.1,8.0 (Windows)
-Comeau 4.3.3
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/doc/named_params.rst b/doc/named_params.rst
deleted file mode 100755
index 96ff7f2..0000000
--- a/doc/named_params.rst
+++ /dev/null
@@ -1,427 +0,0 @@
-++++++++++++++++++++++++++++++++++++++++++
- The Boost.NamedParams Library |(logo)|__
-++++++++++++++++++++++++++++++++++++++++++
-
-.. |(logo)| image:: ../../../c++boost.gif
- :alt: Boost
- :class: boost-logo
-
-__ ../../../index.htm
-
--------------------------------------
-
-
-:Authors: David Abrahams, Daniel Wallin
-:Contact: dave@boost-consulting.com, dalwan01@student.umu.se
-:organizations: `Boost Consulting`_,
-:date: $Date$
-:copyright: Copyright David Abrahams, Daniel Wallin 2003.
-:license: Use, modification and distribution is subject to the
- Boost Software License, Version 1.0. (See accompanying
- file LICENSE_1_0.txt or copy at
- http://www.boost.org/LICENSE_1_0.txt)
-
-.. _`Boost Consulting`: http://www.boost-consulting.com
-.. _`Open Systems Lab`: http://www.osl.iu.edu
-
-.. contents:: Outline
-.. section-numbering::
-
-
-Introduction
-============
-
-In C++ function arguments are given meaning by their position in
-the parameter list. This protocol is fine when there are few
-parameters with default values, but as the number of parameters
-grows, so does the inconvenience of passing arguments in the
-correct order, especially in the presence of default values:
-
- * It can become difficult for readers to understand the meaning of
- arguments at the call site::
-
- window* w = new_window("alert", true, true, false, 77, 65);
-
- * Since meaning is given by position, we have to choose some
- (often arbitrary) order for parameters with default values,
- making some combinations of defaults unusable::
-
- window* new_window(
- char const* name, bool border = true
- , bool opaque = true, bool movable = false
- , int width = 100, int height = 100);
-
- const bool movability = true;
- window* w = new_window("alert2", movability); // error!
-
- * Default values can not depend on the values of other function
- parameters::
-
- window* new_window(
- char const* name, bool border, ...
- , int width = 100, int heigh = width); // error!
-
- * Template types can not be deduced from the default values, so
- we have to resort to overloading to provide default values for
- parameters with template type::
-
- template void f(T x = 0);
-
- f(); // error!
-
-This library is an attempt to address the problems outlined above
-by associating each parameter with a keyword identifier. Using
-this library, users can identify parameters by name instead of just
-argument position::
-
- window* w = new_window("alert2", movable = movability); // OK!
-
-
-.. DWA Daniel, we explicitly *don't* need ref() for the case
- described below. It's only when we want to pass by reference
- without a keyword that we need it.
-
- You also can't start talking about forwarding functions without
- introducing them first!
-
- The tutorial has to come before all the nasty details below.
- I'm going to comment on that and leave the next stuff alone
-
-Tutorial
-========
-
-.. DWA you need some set-up here describing the problem you're
- going to solve.
-
-This example shows how to wrap a function::
-
- void foo(char const* name, float value);
-
-to give both parameters names and default values.
-
-Defining the keywords
----------------------
-
-First we define the named parameter keywords. This is done by creating
-"tag" types for each keyword, and declaring ``keyword<``\ *tag*\
-``>`` objects::
-
- #include
-
- struct name_t; // tag types
- struct value_t;
-
- namespace {
- boost::keyword name; // keyword objects
- boost::keyword value;
- }
-
-Placing these keyword objects in an unnamed namespace will prevent
-link errors when you declare keywords in header files [**Note**:
-the tag types should generally *not* be declared in an unnamed
-namespace]. We also need to create a keywords list for our
-function. These keywords should be declared in the same order as
-their corresponding parameters appear in the function's parameter
-list::
-
- struct foo_keywords
- : boost::keywords<
- name_t
- , value_t
- >
- {};
-
-Defining the forwarding functions
----------------------------------
-
-::
-
- template
- void foo_impl(const Params&);
-
- void foo()
- {
- foo_impl(foo_keywords());
- }
-
- template
- void foo(const A0& a0)
- {
- foo_impl(foo_keywords(a0));
- }
-
- template
- void foo(const A0& a0, const A1& a1)
- {
- foo_impl(foo_keywords(a0, a1));
- }
-
-Defining the implementation function
-------------------------------------
-
-::
-
- template
- void foo_impl(const Params& params)
- {
- std::cout << params[name] << " = " << params[value] << "\n";
- }
-
-That's it. The user calls the ``foo()`` forwarding functions, with
-either positional or named parameters. For instance::
-
- foo("bar", 3.14f);
- foo(value = 6.28f, "baz")
-
-Should print::
-
- bar = 3.14
- baz = 6.28
-
-But we still don't have any default values, leaving any of the
-parameters out results in a compilation error::
-
- foo()
- foo("bar")
- foo(value = 3)
-
-All fails.
-
-Fortunatly, adding default values to parameters is easy::
-
- template
- void foo_impl(const Params& params)
- {
- std::cout
- << params[name | "unnamed"] << " = "
- << params[value | 0] << "\n";
- }
-
-We are using ``operator|`` to denote the default value of a named
-parameter.
-
-Going back a little to the ``foo()`` call that didn't compile::
-
- foo()
- foo("bar")
- foo(value = 3)
-
-Now compiles, and prints::
-
- unnamed = 0
- bar = 0
- unnamed = 3
-
-Limitations of the Approach
-===========================
-
-Because the keywords' ``operator=`` returns a temporary, and
-temporaries cannot be bound to non-``const`` reference parameters,
-our forwarding functions need to take their arguments by ``const``
-reference [#forwarding]_. As a result, an argument which is bound
-to a keyword with ``operator=`` can be transparently passed by
-non-const reference, but positional arguments are always passed by
-``const`` reference unless we use the `Boost.Ref`_ library to
-indicate otherwise::
-
- #include
-
- float x;
- foo(value = x); // held type is float&
- foo(x); // held type is float const&, need help!
- foo(boost::ref(x)); // held type is float&
-
-.. _`Boost.Ref`: ../../bind/ref.hpp
-
-
-Instances of ``boost::reference_wrapper<>`` generated by
-``boost::ref`` will be unwrapped automatically by the library.
-
-Controlling Overload Resolution
-===============================
-
-The parameters of our templated forwarding functions are completely
-general; in fact, they're a perfect match for any argument type
-whatsoever. The problems with exposing such general function
-templates have been the subject of much discussion; especially in
-the presence of `unqualified calls`__. Probably the safest thing
-to do is to isolate the forwarding functions in a namespace
-containing no types [#using]_, but often we'd *like* our functions
-to play nicely with argument-dependent lookup and other function
-overloads. In that case, it's neccessary to somehow remove the
-functions from the overload set when the passed argument types
-don't meet their needs.
-
-__ http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#225
-
-This sort of overload control can be accomplished in C++ by taking
-advantage of SFINAE_ (Substitution Failure Is Not An Error). If
-type substitution during the instantiation of a function template
-results in an invalid type, no compilation error is emitted;
-instead the overload is removed from the overload set. By producing
-an invalid type in the function signature depending on the result
-of some condition, whether or not an overload is considered during
-overload resolution can be controlled. The technique is formalized
-in the |enable_if| utility.
-
-The named parameters library provides built-in SFINAE support
-through the following class template::
-
- template<
- class KeywordTag
- , class HasDefaultValue // mpl::true_ or mpl::false_
- , class Predicate
- >
- struct named_param;
-
-The key parameter, ``Predicate`` shall be a unary MPL lambda
-expression or `Metafunction Class`_ that, when applied to the
-actual type the argument, indicates whether that argument type
-meets the function's requirements for that parameter position.
-
-.. _`Metafunction Class`: ../../mpl/doc/ref/Metafunction_Class.html
-
-.. _SFINAE: http://www.semantics.org/once_weakly/w02_SFINAE.pdf
-
-.. |enable_if| replace:: ``enable_if``
-.. _enable_if: ../enable_if.html
-
-For example, let's say we want to restrict our ``foo()`` so that
-the ``name`` parameter must be convertible to ``const char*``.
-We'll replace our use of the ``name_t`` tag with a specialization
-of ``boost::named_param``:
-
-.. parsed-literal::
-
- struct foo_keywords
- : boost::keywords<
- **boost::named_param<
- name_t
- , mpl::false\_
- , is_convertible
- >**
- , value_t
- >
- {};
-
-Now we can add an additional optional argument to each of our
-``foo`` overloads
-
-.. parsed-literal::
-
- template
- void foo(
- const A0& a0
- , **foo_keywords::restrict::type x = foo_keywords()**
- )
- {
- foo_impl(x(a0));
- }
-
- template
- void foo(
- const A0& a0, const A1& a1
- , **foo_keywords::restrict::type x = foo_keywords()**
- )
- {
- foo_impl(x(a0, a1));
- }
-
-These additional parameters are not intended to be used directly
-by callers; they merely trigger SFINAE by becoming illegal types
-when the ``name`` argument is not convertible to ``const char*``.
-
-Lazy Evaluation of Defaults
-===========================
-
-If computing an argument's default value is expensive, it's best
-avoided when the argument is supplied by the user. In that case,
-the default value can be lazily evaluated using the following
-syntax:
-
-.. parsed-literal::
-
- params[keyword **|| nullary_function**];
-
-``nullary_function`` must be a function object that is callable
-without arguments, and that indicates its return type via a nested
-``result_type``. Boost.Bind can be used to produce an appropriate
-function object from a regular function pointer::
-
- // expensive default computation function
- float default_span(float x, float theta);
-
- // implementation of bar()
- template
- void bar_impl(Params const& params)
- {
- // Extract arguments
- float x_ = params[x];
- float theta_ = params[theta | pi];
- float span = params[span || boost::bind(default_span, x_, theta_)];
- ...
- }
-
-Automatic Overload Generation
-=============================
-
-To reduce the work needed to write functions with named parameters,
-we supply a macro that generates the boilerplate code.
-
-Synopsis::
-
- BOOST_NAMED_PARAMS_FUN(
- return_type, function_name
- , min_arity, max_arity, keywords_type
- );
-
-To generate all the forwarding functions and the implementation
-function for our example, we need only apply
-``BOOST_NAMED_PARAMS_FUN`` this way::
-
- BOOST_NAMED_PARAMS_FUN(void, foo, 0, 2, foo_keywords)
- {
- std::cout
- << p[name | "unnamed"] << " = "
- << p[value | 0] << "\n";
- }
-
-Portability
-===========
-
-Boost.NamedParams has been confirmed to work on the following compilers:
-
- - Microsoft VC6 sp5, VC7 [#norestrict]_
- - Microsoft VC7.1
- - GCC3.3.1 (cygwin), GCC2.95.3 (cygwin), GCC3.2 (mingw)
- - Metrowerks Codewarrior Pro8 and Pro9 (Windows)
- - Intel C++ 5.0,6.0,7.1,8.0 (Windows)
- - Comeau 4.3.3
-
------------------------------
-
-.. [#forwarding] One could provide overloads for ``const`` and
- non-``const`` reference versions of each parameter, but that
- would quickly become unmanageable. It's known as "the
- forwarding problem" and has been described in detail in this
- paper__. The combinatorial explosion is avoided for the
- parameter of keywords' ``operator=`` because they take only a
- single argument.
-
- __ http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1385.htm
-
-
-.. [#using] You can always give the illusion that the function
- lives in an outer namespace by applying a *using-declaration*::
-
- namespace foo_overloads
- {
- // foo declarations here
- void foo() { ... }
- ...
- }
- using foo_overloads::foo;
-
-.. [#norestrict] Restrictions doesn't work on these compilers because
- of lack of SFINAE support.
-
diff --git a/doc/tribool.boostbook b/doc/tribool.boostbook
deleted file mode 100644
index d3280fc..0000000
--- a/doc/tribool.boostbook
+++ /dev/null
@@ -1,167 +0,0 @@
-
-
-
-
-
- Douglas
- Gregor
- gregod@cs.rpi.edu
-
-
-
- 2002
- 2003
- Douglas Gregor
-
-
-
- Permission to copy, use, sell and distribute this software
- is granted provided this copyright notice appears in all copies.
- Permission to modify the code and to distribute modified code is
- granted provided this copyright notice appears in all copies, and
- a notice that the code was modified is included with the copyright
- notice.
-
- This software is provided "as is" without express or
- implied warranty, and with no claim as to its suitability for any
- purpose.
-
-
- Three-state boolean type
-
-
-
-
- Introduction
-
- The 3-state boolean library contains a single class,
- boost::tribool
, along with
- support functions and operator overloads that implement 3-state
- boolean logic.
-
-
-
- Tutorial
-
-
-
- The tribool
class acts
- like the built-in bool
type, but for 3-state boolean
- logic. The three states are true
, false
,
- and indeterminate
, where
- the first two states are equivalent to those of the C++
- bool
type and the last state represents an unknown
- boolean value (that may be true
or
- false
, we don't know).
-
- The tribool
class
- supports conversion from bool
values and literals
- along with its own
- indeterminate
- keyword:
-
- tribool b(true);
-b = false;
-b = indeterminate ;
-tribool b2(b);
-
- tribool
supports
- conversions to bool
for use in conditional
- statements. The conversion to bool
will be
- true
when the value of the
- tribool
is always true, and
- false
otherwise.
-
-tribool b = some_operation();
-if (b) {
- // b is true
-}
-else if (!b) {
- // b is false
-}
-else {
- // b is indeterminate
-}
-
- tribool
supports the
- 3-state logic operators !
(negation),
- &&
(AND), and ||
(OR), with
- bool
and tribool
- values. For instance:
-
- tribool x = some_op();
-tribool y = some_other_op();
-if (x && y) {
- // both x and y are true
-}
-else if (!(x && y)) {
- // either x or y is false
-}
-else {
- // neither x nor y is false, but we don't know that both are true
-
- if (x || y) {
- // either x or y is true, or both
- }
-}
-
- Similarly, tribool
- supports 3-state equality comparisons via the operators
- ==
and !=
. These operators differ from
- "normal" equality operators in C++ because they return a
- tribool
, because potentially we
- might not know the result of a comparison (try to compare
- true
and
- indeterminate
). For
- example:
-
-tribool x(true);
-tribool y(indeterminate );
-
-assert(x == x); // okay, x == x returns true
-assert(!(y == y)); // okay, because y == y is indeterminate
-assert(x == true); // okay, can compare tribool s and bools
-
- The indeterminate
keyword (representing the
- indeterminate tribool
value)
- doubles as a function to check if the value of a
- tribool
is indeterminate,
- e.g.,
-
- tribool x = try_to_do_something_tricky();
-if (indeterminate (x)) {
- // value of x is indeterminate
-}
-else {
- // report success or failure of x
-}
-
- Users may introduce additional keywords for the indeterminate
- value in addition to the implementation-supplied
- indeterminate
using the
- BOOST_TRIBOOL_THIRD_STATE
- macro. For instance, the following macro instantiation (at the
- global scope) will introduce the keyword maybe
as a
- synonym for indeterminate
- (also residing in the boost
namespace):
- BOOST_TRIBOOL_THIRD_STATE (maybe)
-
-
-
-
-
-
- Test all features of the
- boost::tribool
- class.
-
-
-
- Test the use of the
- BOOST_TRIBOOL_THIRD_STATE
- macro.
-
-
-
\ No newline at end of file
diff --git a/include/boost/ref.hpp b/include/boost/ref.hpp
deleted file mode 100644
index 5637545..0000000
--- a/include/boost/ref.hpp
+++ /dev/null
@@ -1,249 +0,0 @@
-#ifndef BOOST_REF_HPP_INCLUDED
-# define BOOST_REF_HPP_INCLUDED
-
-# if _MSC_VER+0 >= 1020
-# pragma once
-# endif
-
-# include
-# include
-# include
-# include
-# ifndef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
-# include
-# endif
-# include
-# include
-
-//
-// ref.hpp - ref/cref, useful helper functions
-//
-// Copyright (C) 1999, 2000 Jaakko Järvi (jaakko.jarvi@cs.utu.fi)
-// Copyright (C) 2001, 2002 Peter Dimov
-// Copyright (C) 2002 David Abrahams
-// Copyright (C) 2003 Doug Gregor
-//
-// Permission to copy, use, modify, sell and distribute this software
-// is granted provided this copyright notice appears in all copies.
-// This software is provided "as is" without express or implied
-// warranty, and with no claim as to its suitability for any purpose.
-//
-// See http://www.boost.org/libs/bind/ref.html for documentation.
-//
-
-# ifndef BOOST_REF_NUM_ARGS
-# define BOOST_REF_NUM_ARGS 10
-# endif
-
-namespace boost
-{
-
-namespace detail { namespace ref {
-
-template
-class reference_wrapper_without_result_type
-{
-public:
- template
- struct result_of
-# ifndef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
- : boost::result_of
-# endif
- {
- };
-
- operator T& () const { return *(this->t_); }
- T& get() const { return *(this->t_); }
- T* get_pointer() const { return this->t_; }
-
-# if !defined(BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION) \
- && !BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x551))
-# define BOOST_PP_ITERATION_PARAMS_1 (3,(0,BOOST_REF_NUM_ARGS,))
-# include BOOST_PP_ITERATE()
-# endif
-
-protected:
-# if defined(BOOST_MSVC) && (BOOST_MSVC < 1300)
- explicit reference_wrapper_without_result_type(T& t) : t_(&t) {}
-# else
- explicit reference_wrapper_without_result_type(T& t) : t_(addressof(t)) {}
-# endif
-
-private:
- T* t_;
-};
-
-# ifndef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
-template
-class reference_wrapper_with_result_type
-{
-public:
- typedef typename T::result_type result_type;
-
- operator T& () const { return *(this->t_); }
- T& get() const { return *(this->t_); }
- T* get_pointer() const { return this->t_; }
-
- result_type operator()() const { return get()(); }
-
-# if !BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x551))
-# define BOOST_PP_ITERATION_PARAMS_1 (3,(0,BOOST_REF_NUM_ARGS,))
-# include BOOST_PP_ITERATE()
-# endif
-
-protected:
-# if defined(BOOST_MSVC) && (BOOST_MSVC < 1300)
- explicit reference_wrapper_with_result_type(T& t) : t_(&t) {}
-# else
- explicit reference_wrapper_with_result_type(T& t) : t_(addressof(t)) {}
-# endif
-
-private:
- T* t_;
-};
-
-template
-class reference_wrapper_impl :
- public ct_if<(has_result_type::value),
- reference_wrapper_with_result_type,
- reference_wrapper_without_result_type >::type
-{
- typedef typename ct_if<(has_result_type::value),
- reference_wrapper_with_result_type,
- reference_wrapper_without_result_type >::type
- inherited;
-
-protected:
- reference_wrapper_impl(T& t) : inherited(t) {}
-};
-# else
-template
-class reference_wrapper_impl : public reference_wrapper_without_result_type
-{
- typedef reference_wrapper_without_result_type inherited;
-
-protected:
- reference_wrapper_impl(T& t) : inherited(t) {}
-};
-# endif
-
-} } // end namespace detail::ref
-
-template
-class reference_wrapper : public detail::ref::reference_wrapper_impl
-{
- typedef detail::ref::reference_wrapper_impl inherited;
-
-public:
- typedef T type;
-
- explicit reference_wrapper(T& t) : inherited(t) {}
-};
-
-# if defined(__BORLANDC__) && (__BORLANDC__ <= 0x570)
-# define BOOST_REF_CONST
-# else
-# define BOOST_REF_CONST const
-# endif
-
-template inline reference_wrapper BOOST_REF_CONST ref(T & t)
-{
- return reference_wrapper(t);
-}
-
-template inline reference_wrapper BOOST_REF_CONST cref(T const & t)
-{
- return reference_wrapper(t);
-}
-
-# undef BOOST_REF_CONST
-
-# ifndef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
-template
-class is_reference_wrapper
-{
- public:
- BOOST_STATIC_CONSTANT(bool, value = false);
-};
-
-template
-class is_reference_wrapper >
-{
- public:
- BOOST_STATIC_CONSTANT(bool, value = true);
-};
-
-template
-class unwrap_reference
-{
- public:
- typedef T type;
-};
-
-template
-class unwrap_reference >
-{
- public:
- typedef T type;
-};
-# else // no partial specialization
-
-} // namespace boost
-
-namespace boost
-{
-
-namespace detail
-{
- typedef char (&yes_reference_wrapper_t)[1];
- typedef char (&no_reference_wrapper_t)[2];
-
- no_reference_wrapper_t is_reference_wrapper_test(...);
-
- template
- yes_reference_wrapper_t
- is_reference_wrapper_test(type< reference_wrapper >);
-
- template
- struct reference_unwrapper
- {
- template
- struct apply
- {
- typedef T type;
- };
- };
-
- template<>
- struct reference_unwrapper
- {
- template
- struct apply
- {
- typedef typename T::type type;
- };
- };
-}
-
-template
-class is_reference_wrapper
-{
- public:
- BOOST_STATIC_CONSTANT(
- bool, value = (
- sizeof(detail::is_reference_wrapper_test(type()))
- == sizeof(detail::yes_reference_wrapper_t)));
-};
-
-template
-class unwrap_reference
- : public detail::reference_unwrapper<
- is_reference_wrapper::value
- >::template apply
-{};
-
-# endif // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
-
-} // namespace boost
-
-#endif // #ifndef BOOST_REF_HPP_INCLUDED
diff --git a/include/boost/utility/enable_if.hpp b/include/boost/utility/enable_if.hpp
deleted file mode 100644
index 02e3678..0000000
--- a/include/boost/utility/enable_if.hpp
+++ /dev/null
@@ -1,87 +0,0 @@
-// Copyright 2003 © The Trustees of Indiana University.
-
-// Boost Software License - Version 1.0 - August 17th, 2003
-
-// Permission is hereby granted, free of charge, to any person or organization
-// obtaining a copy of the software and accompanying documentation covered by
-// this license (the "Software") to use, reproduce, display, distribute,
-// execute, and transmit the Software, and to prepare derivative works of the
-// Software, and to permit third-parties to whom the Software is furnished to
-// do so, all subject to the following:
-
-// The copyright notices in the Software and this entire statement, including
-// the above license grant, this restriction and the following disclaimer,
-// must be included in all copies of the Software, in whole or in part, and
-// all derivative works of the Software, unless such copies or derivative
-// works are solely in the form of machine-executable object code generated by
-// a source language processor.
-
-// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-// FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
-// SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
-// FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
-// ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
-// DEALINGS IN THE SOFTWARE.
-
-// Authors: Jaakko Järvi (jajarvi at osl.iu.edu)
-// Jeremiah Willcock (jewillco at osl.iu.edu)
-// Andrew Lumsdaine (lums at osl.iu.edu)
-
-
-#ifndef BOOST_UTILITY_ENABLE_IF_HPP
-#define BOOST_UTILITY_ENABLE_IF_HPP
-
-namespace boost
-{
-
- template
- struct enable_if_c {
- typedef T type;
- };
-
- template
- struct enable_if_c {};
-
- template
- struct enable_if : public enable_if_c {};
-
- template
- struct lazy_enable_if_c {
- typedef typename T::type type;
- };
-
- template
- struct lazy_enable_if_c {};
-
- template
- struct lazy_enable_if : public lazy_enable_if_c {};
-
-
- template
- struct disable_if_c {
- typedef T type;
- };
-
- template
- struct disable_if_c {};
-
- template
- struct disable_if : public disable_if_c {};
-
- template
- struct lazy_disable_if_c {
- typedef typename T::type type;
- };
-
- template
- struct lazy_disable_if_c {};
-
- template
- struct lazy_disable_if : public lazy_disable_if_c {};
-
-
-
-} // namespace boost
-
-#endif
diff --git a/include/boost/utility/lexicographic.hpp b/include/boost/utility/lexicographic.hpp
deleted file mode 100644
index 69e7713..0000000
--- a/include/boost/utility/lexicographic.hpp
+++ /dev/null
@@ -1,105 +0,0 @@
-// Copyright (c) 2003 Jan Langer
-// Use, modification, and distribution is subject to the Boost Software
-// License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy
-// at http://www.boost.org/LICENSE_1_0.txt)
-
-// See library home page at http://www.boost.org/libs/utility
-
-#ifndef BOOST_UTILITY_LEXICOGRAPHIC_HPP
-#define BOOST_UTILITY_LEXICOGRAPHIC_HPP
-
-namespace boost
-{
-
- class lexicographic
- {
- public:
- enum result_type { minus = -1, equivalent = 0, plus = +1 };
-
- private:
- typedef void (lexicographic::*unspecified_bool_type) ();
- void safe_bool_conversion () {}
-
- template
- result_type do_compare (T1 const &a, T2 const &b) const
- {
- if (a < b)
- return minus;
- else if (b < a)
- return plus;
- else
- return equivalent;
- }
- template
- result_type do_compare (T1 const &a, T2 const &b, Cmp cmp) const
- {
- if (cmp (a, b))
- return minus;
- else if (cmp (b, a))
- return plus;
- else
- return equivalent;
- }
-
- public:
- lexicographic () : m_value (equivalent) {}
-
- template
- lexicographic (T1 const &a, T2 const &b)
- : m_value (do_compare (a, b))
- {}
- template
- lexicographic (T1 const &a, T2 const &b, Cmp cmp)
- : m_value (do_compare (a, b, cmp))
- {}
-
- template
- lexicographic &operator () (T1 const &a, T2 const &b)
- {
- if (m_value == equivalent)
- m_value = do_compare (a, b);
- return *this;
- }
- template
- lexicographic &operator () (T1 const &a, T2 const &b, Cmp cmp)
- {
- if (m_value == equivalent)
- m_value = do_compare (a, b, cmp);
- return *this;
- }
-
- result_type result () const
- {
- return m_value;
- }
-
- operator unspecified_bool_type () const
- {
- return (m_value == minus)
- ? &lexicographic::safe_bool_conversion
- : 0;
- }
-
- // somehow only needed old compilers
- bool operator ! () const
- {
- return m_value != minus;
- }
-
- private:
- result_type m_value;
- };
-
- bool operator == (lexicographic l1, lexicographic l2)
- {
- return l1.result () == l2.result ();
- }
-
- bool operator != (lexicographic l1, lexicographic l2)
- {
- return l1.result () != l2.result ();
- }
-
-} // namespace boost
-
-#endif // BOOST_UTILITY_LEXICOGRAPHIC_HPP
diff --git a/include/boost/utility/select_by_size.hpp b/include/boost/utility/select_by_size.hpp
deleted file mode 100644
index 189b636..0000000
--- a/include/boost/utility/select_by_size.hpp
+++ /dev/null
@@ -1,175 +0,0 @@
-// (C) Copyright Jonathan Turkanis 2004.
-// Permission to copy, use, modify, sell and distribute this software
-// is granted provided this copyright notice appears in all copies. This
-// software is provided "as is" without express or implied warranty, and
-// with no claim as to its suitability for any purpose.
-
-//
-// Intended as an alternative to type_traits::yes_type and type_traits::no_type.
-// Provides an arbitrary number of types (case_<0>, case_<1>, ...) for
-// determining the results of overload resultion using 'sizeof', plus a uniform
-// means of using the result. yes_type and no_type are typedefs for case_<1>
-// and case_<0>. A single case with negative argument, case_<-1>, is also
-// provided, for convenience.
-//
-// This header may be included any number of times, with
-// BOOST_SELECT_BY_SIZE_MAX_CASE defined to be the largest N such that case_
-// is needed for a particular application. It defaults to 2.
-//
-// This header depends only on Boost.Config and Boost.Preprocessor. Dependence
-// on Type Traits or MPL was intentionally avoided, to leave open the
-// possibility that select_by_size could be used by these libraries.
-//
-// Example usage:
-//
-// #define BOOST_SELECT_BY_SIZE_MAX_CASE 7 // Needed for > 2 cases.
-// #include
-//
-// using namespace boost::utility;
-//
-// case_<0> helper(bool); // could use 'case_' or 'no_type'.
-// case_<1> helper(int); // could use 'case_' or' yes_type'.
-// case_<2> helper(unsigned);
-// case_<3> helper(long);
-// case_<4> helper(unsigned long);
-// case_<5> helper(float);
-// case_<6> helper(double);
-// case_<7> helper(const char*);
-//
-// struct test {
-// static const int value =
-// select_by_size< sizeof(helper(9876UL)) >::value;
-// BOOST_STATIC_ASSERT(value == 4);
-// };
-//
-// For compilers with integral constant expression problems, e.g. Borland 5.x,
-// one can also write
-//
-// struct test {
-// BOOST_SELECT_BY_SIZE(int, value, helper(9876UL));
-// };
-//
-// to define a static integral constant 'value' equal to
-//
-// select_by_size< sizeof(helper(9876UL)) >::value.
-//
-
-// Include guards surround all contents of this header except for explicit
-// specializations of select_by_size for case_ with N > 2.
-
-#ifndef BOOST_UTILITY_SELECT_BY_SIZE_HPP_INCLUDED
-#define BOOST_UTILITY_SELECT_BY_SIZE_HPP_INCLUDED
-
-// The lowest N for which select_by_size< sizeof(case_) > has not been
-// specialized.
-#define SELECT_BY_SIZE_MAX_SPECIALIZED 2
-
-#include // BOOST_STATIC_CONSTANT.
-#include
-#include
-#include
-#include
-
-/* Alternative implementation using max_align.
-
-#include
-#include
-
-namespace boost { namespace utility {
-
-template
-struct case_ { char c[(N + 1) * alignment_of::value]; };
-
-template
-struct select_by_size {
- BOOST_STATIC_CONSTANT(int, value =
- (Size / alignment_of::value - 1));
-};
-
-} } // End namespaces utility, boost.
-
-*/ // End alternate implementation.
-
-namespace boost { namespace utility {
-
-//--------------Definition of case_-------------------------------------------//
-
-template struct case_ { char c1; case_ c2; };
-template<> struct case_<-1> { char c; };
-typedef case_ yes_type;
-typedef case_ no_type;
-
-//--------------Declaration of select_by_size---------------------------------//
-
-template struct select_by_size;
-
-} } // End namespaces utility, boost.
-
-//--------------Definition of SELECT_BY_SIZE_SPEC-----------------------------//
-
-// Sepecializes select_by_size for sizeof(case). The decrement is used
-// here because the preprocessor library doesn't handle negative integers.
-#define SELECT_BY_SIZE_SPEC(n) \
- namespace boost { namespace utility { \
- namespace detail { \
- static const int BOOST_PP_CAT(sizeof_case_, n) = sizeof(case_); \
- } \
- template<> \
- struct select_by_size< detail::BOOST_PP_CAT(sizeof_case_, n) > { \
- struct type { BOOST_STATIC_CONSTANT(int, value = n - 1); }; \
- BOOST_STATIC_CONSTANT(int, value = type::value); \
- }; \
- } } \
- /**/
-
-//--------------Default specializations of select_by_size---------------------//
-
-SELECT_BY_SIZE_SPEC(0) // select_by_size< sizeof(case<-1>) >
-SELECT_BY_SIZE_SPEC(1) // select_by_size< sizeof(case<0>) >
-SELECT_BY_SIZE_SPEC(2) // select_by_size< sizeof(case<1>) >
-
-//--------------Definition of SELECT_BY_SIZE----------------------------------//
-
-#define BOOST_SELECT_BY_SIZE(type_, name, expr) \
- BOOST_STATIC_CONSTANT( \
- unsigned, \
- BOOST_PP_CAT(boost_select_by_size_temp_, name) = sizeof(expr) \
- ); \
- BOOST_STATIC_CONSTANT( \
- type_, \
- name = \
- ( boost::utility::select_by_size< \
- BOOST_PP_CAT(boost_select_by_size_temp_, name) \
- >::value ) \
- ) \
- /**/
-
-#endif // #ifndef BOOST_UTILITY_SELECT_BY_SIZE_HPP_INCLUDED
-
-//----------Specializations of SELECT_BY_SIZE (outside main inclued guards)---//
-
-// Specialize select_by_size for sizeof(case_) for each N less than
-// BOOST_SELECT_BY_SIZE_CASES for which this specialization has not already been
-// performed.
-
-#if !BOOST_PP_IS_ITERATING //-------------------------------------------------//
- #include
- #if !defined(BOOST_SELECT_BY_SIZE_MAX_CASE) || \
- (BOOST_SELECT_BY_SIZE_MAX_CASE < 2)
- #undef BOOST_SELECT_BY_SIZE_MAX_CASE
- #define BOOST_SELECT_BY_SIZE_MAX_CASE 2
- #endif
-
- #if (BOOST_SELECT_BY_SIZE_MAX_CASE > SELECT_BY_SIZE_MAX_SPECIALIZED)
- #define BOOST_PP_FILENAME_1
- #define BOOST_PP_ITERATION_LIMITS ( SELECT_BY_SIZE_MAX_SPECIALIZED, \
- BOOST_SELECT_BY_SIZE_MAX_CASE )
- #include BOOST_PP_ITERATE()
- #undef SELECT_BY_SIZE_MAX_SPECIALIZED
- #define SELECT_BY_SIZE_MAX_SPECIALIZED BOOST_SELECT_BY_SIZE_MAX_CASE
- #endif // #if (BOOST_SELECT_BY_SIZE_CASES > SELECT_BY_SIZE_MAX_SPECIALIZED)
-
- #undef BOOST_SELECT_BY_SIZE_MAX_CASE
-#else // #if !BOOST_PP_IS_ITERATING //----------------------------------------//
- SELECT_BY_SIZE_SPEC(BOOST_PP_INC(BOOST_PP_ITERATION()))
-#endif // #if !BOOST_PP_IS_ITERATING //---------------------------------------//
diff --git a/include/boost/utility/type_deduction.hpp b/include/boost/utility/type_deduction.hpp
deleted file mode 100644
index ba07f1f..0000000
--- a/include/boost/utility/type_deduction.hpp
+++ /dev/null
@@ -1,476 +0,0 @@
-/*=============================================================================
- Copyright (c) 2001-2003 Joel de Guzman
-
- Use, modification and distribution is subject to the Boost Software
- License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at
- http://www.boost.org/LICENSE_1_0.txt)
-==============================================================================*/
-#ifndef BOOST_TYPE_DEDUCTION_IPP
-#define BOOST_TYPE_DEDUCTION_IPP
-
-/*=============================================================================
-
- Return Type Deduction
- [JDG Sept. 15, 2003]
-
- Before C++ adopts the typeof, there is currently no way to deduce the
- result type of an expression such as x + y. This deficiency is a major
- problem with template metaprogramming; for example, when writing
- forwarding functions that attempt to capture the essence of an
- expression inside a function. Consider the std::plus:
-
- template
- struct plus : public binary_function
- {
- T operator()(T const& x, T const& y) const
- {
- return x + y;
- }
- };
-
- What's wrong with this? Well, this functor does not accurately capture
- the behavior of the plus operator. 1) It does not handle the case where
- x and y are of different types (e.g. x is short and y is int). 2) It
- assumes that the arguments and return type are the same (i.e. when
- adding a short and an int, the return type ought to be an int). Due to
- these shortcomings, std::plus(x, y) is a poor substitute for x + y.
-
- The case where x is short and y is int does not really expose the
- problem. We can simply use std::plus and be happy that the
- operands x and y will simply be converted to an int. The problem
- becomes evident when an operand is a user defined type such as bigint.
- Here, the conversion to bigint is simply not acceptable. Even if the
- unnecessary conversion is tolerable, in generic code, it is not always
- possible to choose the right T type that can accomodate both x and y
- operands.
-
- To truly model the plus operator, what we need is a polymorphic functor
- that can take arbitrary x and y operands. Here's a rough schematic:
-
- struct plus
- {
- template
- unspecified-type
- operator()(X const& x, Y const& y) const
- {
- return x + y;
- }
- };
-
- Now, we can handle the case where X and Y are arbitrary types. We've
- solved the first problem. To solve the second problem, we need some
- form of return type deduction mechanism. If we had the typeof, it would
- be something like:
-
- template
- typeof(X() + Y())
- operator()(X const& x, Y const& y) const
- {
- return x + y;
- }
-
- Without the typeof facility, it is only possible to wrap an expression
- such as x + y in a function or functor if we are given a hint that
- tells us what the actual result type of such an expression is. Such a
- hint can be in the form of a metaprogram, that, given the types of the
- arguments, will return the result type. Example:
-
- template
- struct result_of_plus
- {
- typedef unspecified-type type;
- };
-
- Given a result_of_plus metaprogram, we can complete our polymorphic
- plus functor:
-
- struct plus
- {
- template
- typename result_of_plus::type
- operator()(X const& x, Y const& y) const
- {
- return x + y;
- }
- };
-
- The process is not automatic. We have to specialize the metaprogram for
- specific argument types. Examples:
-
- template <>
- struct result_of_plus
- {
- typedef int type;
- };
-
- template
- struct result_of_plus, std::complex >
- {
- typedef std::complex type;
- };
-
- To make it easier for the user, specializations are provided for common
- types such as primitive c++ types (e.g. int, char, double, etc.), and
- standard types (e.g. std::complex, iostream, std containers and
- iterators).
-
- To further improve the ease of use, for user defined classes, we can
- supply a few more basic specializations through metaprogramming using
- heuristics based on canonical operator rules (Such heuristics can be
- found in the LL and Phoenix, for example). For example, it is rather
- common that the result of x += y is X& or the result of x || y is a
- bool. The client is out of luck if her classes do not follow the
- canonical rules. She'll then have to supply her own specialization.
-
- The type deduction mechanism demostrated below approaches the problem
- not through specialization and heuristics, but through a limited form
- of typeof mechanism. The code does not use heuristics, hence, no
- guessing games. The code takes advantage of the fact that, in general,
- the result type of an expression is related to one its arguments' type.
- For example, x + y, where x has type int and y has type double, has the
- result type double (the second operand type). Another example, x[y]
- where x is a vector and y is a std::size_t, has the result type
- vector::reference (the vector's reference type type).
-
- The limited form of type deduction presented can detect common
- relations if the result of a binary or unary operation, given arguments
- x and y with types X and Y (respectively), is X, Y, X&, Y&, X*, Y*, X
- const*, Y const*, bool, int, unsigned, double, container and iterator
- elements (e.g the T, where X is: T[N], T*, vector, map,
- vector::iterator). More arguments/return type relationships can be
- established if needed.
-
- A set of overloaded test(T) functions capture these argument related
- types. Each test(T) function returns a distinct type that can be used
- to determine the exact type of an expression.
-
- Consider:
-
- template
- x_value_type
- test(X const&);
-
- template
- y_value_type
- test(Y const&);
-
- Given an expression x + y, where x is int and y is double, the call to:
-
- test(x + y)
-
- will return a y_value_type.
-
- Now, if we rig x_value_type and y_value_type such that both have unique
- sizes, we can use sizeof(test(x + y)) to determine if the result
- type is either X or Y.
-
- For example, if:
-
- sizeof(test(x + y)) == sizeof(y_value_type)
-
- then, we know for sure that the result of x + y has type Y.
-
- The same basic scheme can be used to detect more argument-dependent
- return types where the sizeof the test(T) return type is used to index
- through a boost::mpl vector which holds each of the corresponding
- result types.
-
-==============================================================================*/
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-namespace boost {
-
-struct error_cant_deduce_type {};
-
- namespace type_deduction_detail
- {
- typedef char(&bool_value_type)[1];
- typedef char(&int_value_type)[2];
- typedef char(&uint_value_type)[3];
- typedef char(&double_value_type)[4];
-
- typedef char(&bool_reference_type)[5];
- typedef char(&int_reference_type)[6];
- typedef char(&uint_reference_type)[7];
- typedef char(&double_reference_type)[8];
-
- typedef char(&x_value_type)[9];
- typedef char(&x_reference_type)[10];
- typedef char(&x_const_pointer_type)[11];
- typedef char(&x_pointer_type)[12];
-
- typedef char(&y_value_type)[13];
- typedef char(&y_reference_type)[14];
- typedef char(&y_const_pointer_type)[15];
- typedef char(&y_pointer_type)[16];
-
- typedef char(&container_reference_type)[17];
- typedef char(&container_const_reference_type)[18];
- typedef char(&container_mapped_type)[19];
-
- typedef char(&cant_deduce_type)[20];
-
- template ::type>
- struct is_basic
- : mpl::or_<
- is_same
- , is_same
- , is_same
- , is_same
- > {};
-
- template
- struct reference_type
- {
- typedef typename C::reference type;
- };
-
- template
- struct reference_type
- {
- typedef T& type;
- };
-
- template
- struct reference_type
- {
- typedef T& type;
- };
-
- template
- struct const_reference_type
- {
- typedef typename C::const_reference type;
- };
-
- template
- struct mapped_type
- {
- typedef typename C::mapped_type type;
- };
-
- struct asymmetric;
-
- template
- cant_deduce_type
- test(...); // The black hole !!!
-
- template
- bool_value_type
- test(bool const&);
-
- template
- int_value_type
- test(int const&);
-
- template
- uint_value_type
- test(unsigned const&);
-
- template
- double_value_type
- test(double const&);
-
- template
- bool_reference_type
- test(bool&);
-
- template
- int_reference_type
- test(int&);
-
- template
- uint_reference_type
- test(unsigned&);
-
- template
- double_reference_type
- test(double&);
-
- template
- typename disable_if<
- mpl::or_, is_const >
- , x_value_type
- >::type
- test(X const&);
-
- template
- typename disable_if<
- is_basic
- , x_reference_type
- >::type
- test(X&);
-
- template
- typename disable_if<
- mpl::or_<
- is_basic
- , is_const
- >
- , x_const_pointer_type
- >::type
- test(X const*);
-
- template
- x_pointer_type
- test(X*);
-
- template
- typename disable_if<
- mpl::or_<
- is_basic
- , is_same
- , is_const
- , is_same
- >
- , y_value_type
- >::type
- test(Y const&);
-
- template
- typename disable_if<
- mpl::or_<
- is_basic
- , is_same
- , is_same
- >
- , y_reference_type
- >::type
- test(Y&);
-
- template
- typename disable_if<
- mpl::or_<
- is_same
- , is_const
- , is_same
- >
- , y_const_pointer_type
- >::type
- test(Y const*);
-
- template
- typename disable_if<
- mpl::or_<
- is_same
- , is_same
- >
- , y_pointer_type
- >::type
- test(Y*);
-
- template
- typename disable_if<
- is_basic
- , container_reference_type
- >::type
- test(typename X::reference);
-
- template
- typename enable_if<
- mpl::and_<
- mpl::or_, is_pointer >
- , mpl::not_ >
- >
- , container_reference_type
- >::type
- test(Z&);
-
- template
- typename disable_if<
- is_basic
- , container_const_reference_type
- >::type
- test(typename X::const_reference);
-
- template
- typename disable_if<
- is_basic
- , container_mapped_type
- >::type
- test(typename X::mapped_type);
-
- template
- struct base_result_of
- {
- typedef typename remove_reference::type x_type;
- typedef typename remove_reference::type y_type;
-
- typedef mpl::vector20<
- mpl::identity
- , mpl::identity
- , mpl::identity
- , mpl::identity
- , mpl::identity
- , mpl::identity
- , mpl::identity
- , mpl::identity
- , mpl::identity
- , mpl::identity
- , mpl::identity
- , mpl::identity
- , mpl::identity
- , mpl::identity
- , mpl::identity
- , mpl::identity
- , reference_type
- , const_reference_type
- , mapped_type
- , mpl::identity
- >
- types;
- };
-
-}} // namespace boost::type_deduction_detail
-
-#define BOOST_RESULT_OF_COMMON(expr, name, Y, SYMMETRY) \
- struct name \
- { \
- typedef type_deduction_detail::base_result_of base_type; \
- static typename base_type::x_type x; \
- static typename base_type::y_type y; \
- \
- BOOST_STATIC_CONSTANT(int, \
- size = sizeof( \
- type_deduction_detail::test< \
- typename base_type::x_type \
- , SYMMETRY \
- >(expr) \
- )); \
- \
- BOOST_STATIC_CONSTANT(int, index = (size / sizeof(char)) - 1); \
- \
- typedef typename mpl::at_c< \
- typename base_type::types, index>::type id; \
- typedef typename id::type type; \
- };
-
-#define BOOST_UNARY_RESULT_OF(expr, name) \
- template \
- BOOST_RESULT_OF_COMMON(expr, name, \
- type_deduction_detail::asymmetric, type_deduction_detail::asymmetric)
-
-#define BOOST_BINARY_RESULT_OF(expr, name) \
- template \
- BOOST_RESULT_OF_COMMON(expr, name, Y, typename base_type::y_type)
-
-#define BOOST_ASYMMETRIC_BINARY_RESULT_OF(expr, name) \
- template \
- BOOST_RESULT_OF_COMMON(expr, name, Y, type_deduction_detail::asymmetric)
-
-#endif
diff --git a/ref_call_test.cpp b/ref_call_test.cpp
deleted file mode 100644
index 940d83e..0000000
--- a/ref_call_test.cpp
+++ /dev/null
@@ -1,158 +0,0 @@
-#include
-#include
-#include
-#include
-#include
-
-class generate_zero {
-public:
- typedef int result_type;
- generate_zero() {}
- int operator()() const { return 0; }
-
-private:
- generate_zero(const generate_zero&);
-};
-
-class generate_zero_no_result_type {
-public:
- generate_zero_no_result_type() {}
- int operator()() const { return 0; }
-
-private:
- generate_zero_no_result_type(const generate_zero_no_result_type&);
-};
-
-template
-void check_generate_zero(F f)
-{
- assert(f() == 0);
-}
-
-class negate_with_result_type
-{
-public:
- typedef int result_type;
-
- negate_with_result_type() {}
- int operator()(int x) const { return -x; }
-
-private:
- negate_with_result_type(const negate_with_result_type&);
-};
-
-class negate_with_result_of
-{
-public:
- template
- struct result_of
- {
- typedef int type;
- };
-
- negate_with_result_of() {}
- int operator()(int x) const { return -x; }
-
-private:
- negate_with_result_of(const negate_with_result_of&);
-};
-
-template
-void check_negate(F f)
-{
- int x = 5;
- assert(f(x) == -x);
-}
-
-class add_with_result_type
-{
-public:
- typedef int result_type;
-
- add_with_result_type() {}
- int operator()(int x, int y) const { return x + y; }
-
-private:
- add_with_result_type(const add_with_result_type&);
-};
-
-class add_with_result_of
-{
-public:
- template struct result_of { typedef int type; };
-
- add_with_result_of() {}
- int operator()(int x, int y) const { return x + y; }
-
-private:
- add_with_result_of(const add_with_result_of&);
-};
-
-template
-void check_sum(F f)
-{
- int x = 3;
- int y = 5;
- assert(f(x, y) == x+y);
-}
-
-struct zero_negate_add_result_type
-{
-public:
- typedef int result_type;
-
- zero_negate_add_result_type() {}
- int operator()() const { return 0; }
- int operator()(int x) const { return -x; }
- int operator()(int x, int y) const { return x+y; }
-
-private:
- zero_negate_add_result_type(const zero_negate_add_result_type&);
-};
-
-struct zero_negate_add_result_of
-{
-public:
- template