|
|
Boost-Commit : |
Subject: [Boost-commit] svn:boost r67521 - sandbox/tti/libs/tti/doc
From: eldiener_at_[hidden]
Date: 2010-12-31 12:03:53
Author: eldiener
Date: 2010-12-31 12:03:48 EST (Fri, 31 Dec 2010)
New Revision: 67521
URL: http://svn.boost.org/trac/boost/changeset/67521
Log:
Updated docs
Added:
sandbox/tti/libs/tti/doc/TTIWhy.qbk (contents, props changed)
Text files modified:
sandbox/tti/libs/tti/doc/TTIDetail.qbk | 19 ++++---
sandbox/tti/libs/tti/doc/TTIFunctionality.qbk | 69 ++++++++------------------
sandbox/tti/libs/tti/doc/TTIIntroduction.qbk | 29 +++++++---
sandbox/tti/libs/tti/doc/TTIMetafunctions.qbk | 103 +++++++++++++++++++++++++++++----------
sandbox/tti/libs/tti/doc/TTINestedType.qbk | 77 +++++++++++++----------------
sandbox/tti/libs/tti/doc/TTITerminology.qbk | 2
sandbox/tti/libs/tti/doc/TypeTraitsIntrospection.qbk | 1
7 files changed, 166 insertions(+), 134 deletions(-)
Modified: sandbox/tti/libs/tti/doc/TTIDetail.qbk
==============================================================================
--- sandbox/tti/libs/tti/doc/TTIDetail.qbk (original)
+++ sandbox/tti/libs/tti/doc/TTIDetail.qbk 2010-12-31 12:03:48 EST (Fri, 31 Dec 2010)
@@ -1,20 +1,23 @@
[section:tti_detail Macros]
-The TTI library uses macros to create metafunctions, in the top-level tti namespace,
+The TTI library uses macros to create metafunctions, in the top-level 'tti' namespace,
for introspecting an inner element by name. Each macro for a particular type of inner
element has two forms, the simple one where the first macro parameter designating the
'name' of the inner element is used to create the name of the metafunction, and the
-slightly more complicated one where the first macro parameter, called 'trait', designates
+complex one where the first macro parameter, called 'trait', designates
the name of the metafunction and the second macro parameter designates the 'name' to be queried.
Other than that difference, the two forms of the macro produce the exact same results.
-All of the querying macros create a metafunction whose boolean 'value' specifies
+All of the introspecting macros create a metafunction whose boolean 'value' specifies
whether or not the inner element exists.
+To use these metafunctions you need to include the main header file 'TTIntrospection.hpp',
+unless otherwise noted.
+
A table of these macros is given, with the inner element whose
-existence the metaprogrammer is querying. A more detailed explanation can be found
+existence the metaprogrammer is introspecting. A more detailed explanation can be found
in the reference section. In the Template column only the name generated by the simple form
-of the template is given since the name generated by the more complicated form is always tti::trait
-where 'trait' is the first parameter to the corresponding macro.
+of the template is given since the name generated by the complex form is always tti::trait
+where 'trait' is the first parameter to the corresponding complex form macro.
[table:tbmacros TTI Macros
[
@@ -101,9 +104,9 @@
]
]
-There is one other macro which creates a metafunction which does not query
+There is one other macro which creates a metafunction which does not introspect
for the existence of an inner element type, but is very useful nonetheless.
-Instead the metafunction created returns the nested type if it exists, else
+Instead the macro metafunction created returns the nested type if it exists, else
it returns an unspecified type.
[table:tbmacronested TTI Nested Type Macro
Modified: sandbox/tti/libs/tti/doc/TTIFunctionality.qbk
==============================================================================
--- sandbox/tti/libs/tti/doc/TTIFunctionality.qbk (original)
+++ sandbox/tti/libs/tti/doc/TTIFunctionality.qbk 2010-12-31 12:03:48 EST (Fri, 31 Dec 2010)
@@ -18,11 +18,11 @@
a particular name. In order to do this using template metaprogramming, macros are used
so that the name of the inner element can be passed to the macro. The macro will then
generate an appropriate metafunction, which the template metaprogrammer can then use to
-query the information that is needed. The name itself of the inner element is always passed
-to the macro as a macro parameter, but other macro parameters may be needed also in some cases.
+introspect the information that is needed. The name itself of the inner element is always passed
+to the macro as a macro parameter, but other macro parameters may also be needed in some cases.
-All of the macros start with the prefix TTI_, create their metafunctions in the top-level
-tti namespace, and come in two forms:
+All of the macros start with the prefix TTI_, create their metafunctions in a top-level
+namespace called 'tti, and come in two forms:
# In the simplest form the 'name' of the inner element is used directly to generate the name
of the metafunction as well as serving as the 'name' to introspect. The 'name' is appended
@@ -30,50 +30,23 @@
macro part of the name in lower case. As an example, for the macro TTI_HAS_TYPE(MyType) the
name of the metafunction is 'tti::has_type_MyType' and it will look for an inner type
called 'MyType'.
-# In the slightly more complicated form the macro starts with TTI\_TRAIT\_ and a 'trait' name is
- passed as the first parameter, with the 'name' of the inner element as the second parameter.
- The 'trait' serves only to completely name the metafunction in the tti namespace. As an example,
- for the macro TTI_TRAIT_HAS_TYPE(MyTrait,MyType) the name of the metafunction is 'tti::MyTrait' and it will
- look for an inner type called 'MyType'.
+# In the slightly more complicated form which I call the complex form, the macro starts with
+ TTI\_TRAIT\_ and a 'trait' name is passed as the first parameter, with the 'name' of the inner
+ element as the second parameter. The 'trait' serves only to completely name the metafunction in
+ the tti namespace. As an example, for the macro TTI_TRAIT_HAS_TYPE(MyTrait,MyType) the name of
+ the metafunction is 'tti::MyTrait' and it will look for an inner type called 'MyType'.
-[important Any given metafunction generated, when introspecting a particular inner element, can be reused
-for any combination of template parameters which involve the same type of inner element. Once a metafunction
-is generated, attempting to generate another metafunction of the same name will create ODR violations since
-two C++ constructs with the same name/type in the same namespace will have been created. This latter
-possibility has much less chance of occurence if you use the simple form of each macro and just reuse
-the metafunction if you are querying for two entities of the same name in different enclosing types, or in
-the same enclosing type but with different signatures.]
+[important Any given macro metafunction generated, when introspecting a particular inner element, can be reused
+for any combination of template parameters which involve the same type of inner element. Once a macro metafunction
+is generated, attempting to generate another macro metafunction of the same name will create ODR violations since
+two C++ constructs with the same name/type in the same namespace will have been created. This latter possibility
+has much less chance of occurence if you use the simple form of each macro and just reuse
+the macro metafunction. You can even do this if you are introspecting for two entities of the same name in
+different enclosing types, or in the same enclosing type but with different signatures,
+as with overloaded member functions.]
+
+Once either of these two macro forms are used for a particular type of inner element, the
+corresponding macro metafunction has the exact same functionality. I refer to these two macros as
+a macro pair.
-[section:tti_reason Why the TTI Library ?]
-
-In the Boost Type Traits library there is compile time functionality for
-querying information about a C++ type. This information is very useful
-during template metaprogramming and forms the basis, along with the
-constructs of the Boost MPL library, and some other compile time
-libraries, for much of the template metaprogramming in Boost.
-
-One area which is mostly missing in the Type Traits library is the ability
-to determine what C++ inner elements are part of a type, where the inner
-element may be a nested type, function or data member, static function or
-static data member, or class template.
-
-There has been some of this functionality in Boost, both in already existing
-libraries and in libraries on which others have worked but which were
-never submitted for acceptance into Boost. An example with an existing Boost
-library is Boost MPL, where there is functionality, in the form of macros,
-to determine whether an enclosing type has a particular nested type or nested
-class template. An example with a library which was never submitted to Boost
-is the Concept Traits Library from which much of the functionality of this
-library, related to type traits, was taken and improved upon.
-
-It may also be possible that some other Boost libraries, highly dependent
-on advanced template metaprogramming techniques, also have internal
-functionality to query a type's elements at compile time. But to the best
-of my knowledge this sort of functionality has never been incorporated in
-a single Boost library. This library is an attempt to do so, and to bring
-a recognizable set of interfaces to compile-time type introspection to Boost
-so that other metaprogramming libraries can use them for their own needs.
-
-[endsect]
-
[endsect]
Modified: sandbox/tti/libs/tti/doc/TTIIntroduction.qbk
==============================================================================
--- sandbox/tti/libs/tti/doc/TTIIntroduction.qbk (original)
+++ sandbox/tti/libs/tti/doc/TTIIntroduction.qbk 2010-12-31 12:03:48 EST (Fri, 31 Dec 2010)
@@ -3,9 +3,9 @@
Welcome to the Type Traits Introspection library version 1.0 .
The Type Traits Introspection library, or TTI for short, is a library
-of macros generating metafunctions, and a set of metafunctions themselves,
-which provide the ability to introspect by name the elements of a type at
-compile time.
+of macros generating metafunctions, and a set of parallel nested type
+metafunctions, which provide the ability to introspect by name the
+elements of a type at compile time.
The name of the library is chosen because the library offers
compile time functionality on a type, as does the Boost Type Traits library,
@@ -13,9 +13,12 @@
a type about the existence of a specific element.
I use the word "introspect" in a very broad sense here. Normally language
-introspection means asking for information to be initially returned by name.
+introspection means initially asking for information to be initially returned by name.
In the TTI library one must always supply the name, and use the functionality
-for the correct type of element to find out if the particular named entity exists.
+for the correct type of inner element to find out if the particular named entity exists.
+You may prefer the term "query" instead of "introspection" to denote what this
+library does, but I use terminology based on the word "introspect" throughout
+this documentation.
The functionality of the library may be summed up as:
@@ -23,14 +26,16 @@
using a set of macros. Each macro takes the name of the
type's element and generates a metafunction which can be
subsequently invoked to determine whether or not the
- element exists within the type.
+ element exists within the type. These metafunctions
+ will be called macro metafunctions in the documentation.
# Provide corresponding metafunctions which can operate
on each of the macro metafunctions generated.
These secondary metafunctions provide
the same set of introspection as the primary ones but
allow nested types, which do not actually have to exist,
to be passed in template parameters without producing
- a compiler error.
+ a compiler error. These metafunctions will be called
+ nested type metafunctions in the documentation.
The library is a header only library.
@@ -39,10 +44,16 @@
functionality supporting variadic macros is to be used.
# The main header, which does not require using the library
-support for variadic macros, is 'TTIntrospection.hpp'.
+support for variadic macros, is 'TTIntrospection.hpp'. This
+can be used for the vast majority of functionality in the library.
# The secondary header, which uses a very small subset of the
library functionality, providing an alternate use of a particular
macro with variadic macro support, is 'TTIntrospectionVM.hpp'.
+
+Furthermore there is a third header file which both of the header
+files above include, called 'TTIntrospectionTemplate.hpp' but
+this should never be included itself but only through either
+of the main header files.
The library is dependent on Boost PP, Boost MPL,
Boost Type Traits, and Boost Function Types.
@@ -50,7 +61,7 @@
If the secondary header is used the library is also dependent
on the variadic_macro_data library currently in the sandbox.
If the secondary header is not used there is no need to download
-the variadic_macro_data library and use it.
+the variadic_macro_data library and use it in any way.
Since the dependencies of the library are all header only
libraries, there is no need to build anything in order to use
Modified: sandbox/tti/libs/tti/doc/TTIMetafunctions.qbk
==============================================================================
--- sandbox/tti/libs/tti/doc/TTIMetafunctions.qbk (original)
+++ sandbox/tti/libs/tti/doc/TTIMetafunctions.qbk 2010-12-31 12:03:48 EST (Fri, 31 Dec 2010)
@@ -1,10 +1,32 @@
[section:tti_metafunctions Metafunctions]
+The nested type metafunctions parallel the macro metafunctions but allow
+nested types to be used without compiler errors and without needing to use the
+T::InnerType notation for nested types.
+
+For each of these metafunctions the first parameter is the class template of its corresponding macro metafunction
+and the remaining parameter are 'types', which always consists first of the enclosing type and then
+possibly other types which make up the signature of whatever inner element we are introspecting. Each of these
+'types' is passed as a nullary metafunction whose typedef 'type' is the actual type.
+
+It is important to understand what this accomplishes. For a type which is in scope, we can always use
+boost::mpl::identity to create our nullary metafunction, and there can never be a compiler error for
+such known types as long as such declarations for them exist. For nested types, which may or may not
+exist, we can pass the result of the macro pair TTI\_MEMBER\_TYPE ( TTI\_TRAIT\_MEMBER\_TYPE ) or its equivalent
+nested type metafunction tti::mf\_member\_type ( explained later ).
+
+To use these metafunctions you need to include the main header file 'TTIntrospection.hpp',
+unless otherwise noted.
+
+[tip The header file <boost/mpl/identity.hpp> is included by the TTI header files so you need not
+manually include it in order to use boost::mpl::identity to wrap a known type as a nullary
+metafunction for the nested type metafunctions.]
+
A table of these metafunctions is given, based on the inner element whose
-existence the metaprogrammer is querying. A more detailed explanation can be found
-in the reference section. All of the metafunctions are in the tti top-level namespace,
-all have a particular name, and all begin with the prefix 'mf_' so as not to conflict with
-the macro metafunctions in the library.
+existence the metaprogrammer is introspecting. A more detailed explanation can be found
+in the reference section. All of the metafunctions are in the top-level 'tti' namespace,
+all have a particular name based on the type of its functionality, and all begin with the prefix
+'mf_' so as not to conflict with the macro metafunctions in the library.
[table:tbmetafunctions TTI Metafunctions
[
@@ -15,68 +37,88 @@
]
[
[Type]
- [tti::mf_has_type]
+ [tti::mf\_has\_type]
[
- template<class> class HasType = generated macro metafunction[br]
+ template<class> class HasType[br]
+ = generated macro metafunction[br]
class T = enclosing type nullary metafunction
]
- [TTI_HAS_TYPE (TTI_TRAIT_HAS_TYPE)]
+ [TTI\_HAS\_TYPE (TTI\_TRAIT\_HAS\_TYPE)]
]
[
[Type with check]
- [tti::mf_has_type_check_typedef]
+ [tti::mf\_has\_type\_check\_typedef]
[
- template<class,class> class HasTypeCheckTypedef = generated macro metafunction[br]
+ template<class,class> class HasTypeCheckTypedef[br]
+ = generated macro metafunction[br]
class T = enclosing type nullary metafunction[br]
class U = type to check against nullary metafunction
]
- [TTI_HAS_TYPE_CHECK_TYPEDEF (TTI_TRAIT_HAS_TYPE_CHECK_TYPEDEF)]
+ [TTI\_HAS\_TYPE\_CHECK\_TYPEDEF (TTI\_TRAIT\_HAS\_TYPE\_CHECK\_TYPEDEF)]
+ ]
+ [
+ [Template]
+ [tti::mf\_has\_template]
+ [
+ template<class,class> class HasTemplate[br]
+ = generated macro metafunction[br]
+ class T = enclosing type nullary metafunction
+ ]
+ [
+ TTI\_HAS\_TEMPLATE (TTI\_TRAIT\_HAS\_TEMPLATE)[br]
+ TTI\_HAS\_TEMPLATE\_CHECK\_PARAMS (TTI\_TRAIT\_HAS\_TEMPLATE\_CHECK\_PARAMS)[br]
+ TTI\_VM\_HAS\_TEMPLATE\_CHECK\_PARAMS (TTI\_VM\_TRAIT\_HAS\_TEMPLATE\_CHECK\_PARAMS)
+ ]
]
[
[Member data]
- [tti::mf_has_member_data]
+ [tti::mf\_has\_member\_data]
[
- template<class> class HasMember = generated macro metafunction[br]
+ template<class> class HasMember[br]
+ = generated macro metafunction[br]
class T = enclosing type nullary metafunction[br]
class R = type of member data nullary Metafunction
]
- [TTI_HAS_MEMBER (TTI_TRAIT_HAS_MEMBER)]
+ [TTI\_HAS\_MEMBER (TTI\_TRAIT\_HAS\_MEMBER)]
]
[
[Member function]
- [tti::mf_has_member_function]
+ [tti::mf\_has\_member\_function]
[
- template<class> class HasMember = generated macro metafunction[br]
+ template<class> class HasMember[br]
+ = generated macro metafunction[br]
class T = enclosing type nullary metafunction[br]
class R = return value nullary metafunction[br]
class Types... = parameter types as nullary metafunctions
]
- [TTI_HAS_MEMBER (TTI_TRAIT_HAS_MEMBER)]
+ [TTI\_HAS\_MEMBER (TTI\_TRAIT\_HAS\_MEMBER)]
]
[
[Static data]
- [tti::mf_has_static_data]
+ [tti::mf\_has\_static\_data]
[
- template<class,class> class HasStaticMember = generated macro metafunction[br]
+ template<class,class> class HasStaticMember[br]
+ = generated macro metafunction[br]
class T = enclosing type nullary metafunction[br]
class R = type of static data nullary metafunction
]
- [TTI_HAS_STATIC_MEMBER (TTI_TRAIT_HAS_STATIC_MEMBER)]
+ [TTI\_HAS\_STATIC\_MEMBER (TTI\_TRAIT\_HAS\_STATIC\_MEMBER)]
]
[
[Static function]
- [tti::mf_has_static_function]
+ [tti::mf\_has\_static\_function]
[
- template<class,class> class HasStaticMember = generated macro metafunction[br]
+ template<class,class> class HasStaticMember[br]
+ = generated macro metafunction[br]
class T = enclosing type nullary metafunction[br]
class R = return value nullary metafunction[br]
class Types... = parameter types as nullary metafunctions
]
- [TTI_HAS_STATIC_MEMBER (TTI_TRAIT_HAS_STATIC_MEMBER)]
+ [TTI\_HAS\_STATIC\_MEMBER (TTI\_TRAIT\_HAS\_STATIC\_MEMBER)]
]
]
-Just as there is the macro TTI_MEMBER_TYPE (TTI_TRAIT_MEMBER_TYPE) for creating
+Just as there is the macro pair TTI\_MEMBER\_TYPE (TTI\_TRAIT\_MEMBER\_TYPE) for creating
a macro metafunction which returns a nested type if it exists, else an unspecified
type, there is also the equivalent metafunction.
@@ -89,13 +131,22 @@
]
[
[Type]
- [tti::mf_member_type]
+ [tti::mf\_member\_type]
[
- template<class> class MemberType = generated macro metafunction[br]
+ template<class> class MemberType[br]
+ = generated macro metafunction[br]
class T = enclosing type nullary metafunction
]
- [TTI_MEMBER_TYPE (TTI_TRAIT_MEMBER_TYPE)]
+ [TTI\_MEMBER\_TYPE (TTI\_TRAIT\_MEMBER\_TYPE)]
]
]
+The use of this metafunction allows us to created deeply nested types,
+which may or may not exist, as nullary metafunctions. This then can
+be used with the other nested type metafunctions above. The key
+information above is that the enclosing type is a nullary metafunction,
+which means that the enclosing type can be specified as the result
+of using TTI\_MEMBER\_TYPE (TTI\_TRAIT\_MEMBER\_TYPE) as well as the
+result of using itself.
+
[endsect]
Modified: sandbox/tti/libs/tti/doc/TTINestedType.qbk
==============================================================================
--- sandbox/tti/libs/tti/doc/TTINestedType.qbk (original)
+++ sandbox/tti/libs/tti/doc/TTINestedType.qbk 2010-12-31 12:03:48 EST (Fri, 31 Dec 2010)
@@ -4,43 +4,47 @@
The goal of the TTI library is never to produce a compiler error by just
using the functionality in the library, whether it is invoking its function-like macros
-or instantiating the metafunctions created by them. In this sense The TTI library macros
-for querying an enclosing type for an inner element work very well, except in one general case.
-That general case is the crux of the discussion regarding nested types which follows,
-and explains the reason for the separate group of TTI metafunctions which mirror the
-functionality of the macros and their generated metafunctions.
+or instantiating the macro metafunctions created by them, and whether the inner element exists
+or not. In this sense The TTI library macros for introspecting an enclosing type for
+an inner element work very well. But there is one exception to this general case.
+That exception is the crux of the discussion regarding nested types which follows,
+and explains the reason for the separate group of TTI nested type metafunctions which mirror the
+functionality of the macros and their generated macro metafunctions.
The metafunctions generated by the TTI macros all work with types, whether in specifying
-an enclosing type or in specifying the type of some inner element. The C++ notation for
-a nested type, given an enclosing type 'E' and an inner type 'I', is 'E::I'. If either the
-enclosing type 'E' does not exist, or the inner type 'I' does not exist within 'E', the expression
-'E::I' will give a compiler error if we attempt to use it in our template instantiation
-of one of TTI's macro metafunctions. We want to be able to query for the existence of inner
-elements to an enclosing type without producing compiler errors. Of course if we absolutely
-know what types we have and that a nested type exists we can always use an expression like
-E::I without error, or even E::I::AnotherInnerType as we drill down further into nested types.
-But this is often not the case when doing template programming since the type being
-passed to us at compile-time in a class or function template is chosen at instantiation
-time.
+an enclosing type or in specifying the type of some inner element, which may also involve
+types in the signature of that element. The C++ notation for
+a nested type, given an enclosing type 'T' and an inner type 'InnerType', is 'T::InnerType'. If either
+the enclosing type 'T' does not exist, or the inner type 'InnerType' does not exist within 'T',
+the expression 'T::InnerType' will give a compiler error if we attempt to use it in our template
+instantiation of one of TTI's macro metafunctions.
+
+We want to be able to introspect for the existence of inner elements to an enclosing type
+without producing compiler errors. Of course if we absolutely know what types we have and
+that a nested type exists, and these declarations are within our scope, we can always use
+an expression like T::InnerType without error. But this is often not the case when doing template
+programming since the type being passed to us at compile-time in a class or function template
+is chosen at instantiation time.
-One solution to this is afforded by the library itself. Given an enclosing type 'E'
+One solution to this is afforded by the library itself. Given an enclosing type 'T'
which we know must exist, either because it is a top-level type we know about or
-it is passed to us in some template as a 'class E' or 'typename E', and given an inner type
-named 'I' whose existence we would like ascertain, we can use a TTI_HAS_TYPE(I) macro and it's related
-tti::has_type_I metafunction to determine if the nested type 'I' exists. This solution is perfectly valid
+it is passed to us in some template as a 'class T' or 'typename T', and given an inner type
+named 'InnerType' whose existence we would like ascertain, we can use a TTI_HAS_TYPE(InnerType) macro and it's related
+tti::has_type_InnerType metafunction to determine if the nested type 'InnerType' exists. This solution is perfectly valid
and, with Boost MPL's selection metafunctions, we can do compile-time selection to generate the
correct template code.
However this does not scale that well syntactically if we need to drill down further from a
-top-level enclosing type to a deeply nested type. We are going to be generating a great deal
-of boost::mpl::if_ and/or boost::mpl::eval_if type selection statements to get to some
-final condition where we know we can generate the compile-time code which we want.
+top-level enclosing type to a deeply nested type, or even to look for some deeply nested type's
+inner elements. We are going to be generating a great deal of boost::mpl::if_ and/or
+boost::mpl::eval_if type selection statements to get to some final condition where we know we
+can generate the compile-time code which we want.
[heading The Solution]
The TTI library offers a better solution in the form of a set of constructs which work with
nested types without producing a compiler error if the nested type does not exist, but still
-are able to do the querying for inner elements that our TTI macro metafunctions do.
+are able to do the introspecting for inner elements that our TTI macro metafunctions do.
We have already seen one of those constructs, the macro TTI_MEMBER_TYPE
( and equivalent TTI_TRAIT_MEMBER_TYPE ), which generates a metafunction based on the name
@@ -49,23 +53,12 @@
does not. In this way we have created a metafunction, very similar in functionality to
boost::mpl::identity, but which still returns some marker 'type' if our nested type is invalid.
-The remaining metafunctions in the TTI library use this concept of a nested type which does
-not exist not producing a compiler error to query the same things that our macro metafunctions
-do, but without having to use the notation 'E::I' to express a nested type.
-
-For each of these metafunctions the first class template parameter is its corresponding macro metafunction
-template and the remaining parameter are 'types', which always consists first of the enclosing type and then
-possibly other types which make up the signature of whatever inner element we are querying. The most important
-thing to understand about these 'types' is that they are passed in the form of a nullary metafunction
-whose typedef 'type' is the actual type. This lets us pass not only the result of
-TTI_MEMBER_TYPE ( TTI_TRAIT_MEMBER_TYPE ) as one of the 'types', which may not actually exist, but also
-the result of its equivalent metafunction, tti::mf_member_type ( explained later ). For a type not
-generated by either the TTI_MEMBER_TYPE ( TTI_TRAIT_MEMBER_TYPE ) macro metafunction or tti::mf_member_type
-metafunction, and therefore exists in our scope, we can use boost::mpl::identity to create our
-nullary metafunction.
-
-[tip The header file <boost/mpl/identity.hpp> is included by the TTI main header file TTIntrospection.hpp
-so you need not manually include it in order to use boost::mpl::identity to wrap a known type as a nullary
-metafunction for the TTI metafunctions.]
+The remaining nested type metafunctions in the TTI library use this concept of a nested type which does
+not exist not producing a compiler error to introspect the same things that our macro metafunctions
+do, but without having to use the notation 'T::InnerType' to express a nested type. Because of this we
+can avoid a compiler error when attempting to introspect enclosing types, where they may be nested types,
+or specifying the signature of inner elements which may involve nested types.
+
+These nested type metafunctions,and how they work, are more fully explained in our next section.
[endsect]
Modified: sandbox/tti/libs/tti/doc/TTITerminology.qbk
==============================================================================
--- sandbox/tti/libs/tti/doc/TTITerminology.qbk (original)
+++ sandbox/tti/libs/tti/doc/TTITerminology.qbk 2010-12-31 12:03:48 EST (Fri, 31 Dec 2010)
@@ -12,7 +12,7 @@
functions or data that are part of the enclosing type.
I use the term "static member function" or "static member data" to refer to static
functions or data that are part of the enclosing type.
-I use the term "class template member" to refer to a class template
+I use the term "nested class template" to refer to a class template
nested within the enclosing type.
Other terminology may be just as valid for the notion of C++ language
Added: sandbox/tti/libs/tti/doc/TTIWhy.qbk
==============================================================================
--- (empty file)
+++ sandbox/tti/libs/tti/doc/TTIWhy.qbk 2010-12-31 12:03:48 EST (Fri, 31 Dec 2010)
@@ -0,0 +1,31 @@
+[section:tti_reason Why the TTI Library ?]
+
+In the Boost Type Traits library there is compile time functionality for
+querying information about a C++ type. This information is very useful
+during template metaprogramming and forms the basis, along with the
+constructs of the Boost MPL library, and some other compile time
+libraries, for much of the template metaprogramming in Boost.
+
+One area which is mostly missing in the Type Traits library is the ability
+to determine what C++ inner elements are part of a type, where the inner
+element may be a nested type, function or data member, static function or
+static data member, or class template.
+
+There has been some of this functionality in Boost, both in already existing
+libraries and in libraries on which others have worked but which were
+never submitted for acceptance into Boost. An example with an existing Boost
+library is Boost MPL, where there is functionality, in the form of macros and metafunctions,
+to determine whether an enclosing type has a particular nested type or nested
+class template. An example with a library which was never submitted to Boost
+is the Concept Traits Library from which much of the functionality of this
+library, related to type traits, was taken and improved upon.
+
+It may also be possible that some other Boost libraries, highly dependent
+on advanced template metaprogramming techniques, also have internal
+functionality to introspect a type's elements at compile time. But to the best
+of my knowledge this sort of functionality has never been incorporated in
+a single Boost library. This library is an attempt to do so, and to bring
+a recognizable set of interfaces to compile-time type introspection to Boost
+so that other metaprogramming libraries can use them for their own needs.
+
+[endsect]
Modified: sandbox/tti/libs/tti/doc/TypeTraitsIntrospection.qbk
==============================================================================
--- sandbox/tti/libs/tti/doc/TypeTraitsIntrospection.qbk (original)
+++ sandbox/tti/libs/tti/doc/TypeTraitsIntrospection.qbk 2010-12-31 12:03:48 EST (Fri, 31 Dec 2010)
@@ -11,6 +11,7 @@
]
[include TTIIntroduction.qbk]
+[include TTIWhy.qbk]
[include TTITerminology.qbk]
[include TTIFunctionality.qbk]
[include TTIDetail.qbk]
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk