[Boost-commit] svn:boost r70446 - sandbox/tti/libs/tti/doc

Subject: [Boost-commit] svn:boost r70446 - sandbox/tti/libs/tti/doc
From: eldiener_at_[hidden]
Date: 2011-03-22 20:11:29

Author: eldiener
Date: 2011-03-22 20:11:27 EDT (Tue, 22 Mar 2011)
New Revision: 70446
URL: http://svn.boost.org/trac/boost/changeset/70446

Log:
Added new documentation section.
Added:
   sandbox/tti/libs/tti/doc/tti_func_templates.qbk   (contents, props changed)

Added: sandbox/tti/libs/tti/doc/tti_func_templates.qbk
==============================================================================
--- (empty file)
+++ sandbox/tti/libs/tti/doc/tti_func_templates.qbk	2011-03-22 20:11:27 EDT (Tue, 22 Mar 2011)
@@ -0,0 +1,155 @@
+[section:tti_func_templates Introspecting Function Templates]
+
+The one nested element which the TTI library does not introspect is 
+function templates.
+
+Function templates, like functions, can be member function templates or 
+static member function templates. In this respect they are related to 
+functions. Function templates represent a family of possible functions.
+In this respect they are similar to class templates, which represent a 
+family of possible class types.
+
+The technique for introspecting class templates in the TTI library is taken 
+from the implementation of the technique in the Boost MPL library. In the case
+of `BOOST_TTI_HAS_TEMPLATE` it directly uses the Boost MPL library functionality 
+while in the case of `BOOST_TTI_HAS_TEMPLATE_CHECK_PARAMS` it replicates much 
+of the technique in the Boost MPL library. The technique depends directly on 
+the fact that in C++ we can pass a template as a parameter to another template
+using what is called a "template template" parameter type. 
+
+One obvious thing about a template template parameter type is that it is a 
+class template. For whatever historical or technical reasons, no one has ever
+proposed that C++ have a way of passing a function template directly as a template 
+parameter, perhaps to be called a "function template template" parameter type. 
+I personally think this would be a good addition to C++ and would 
+make the ability of passing a template as a parameter to another template 
+more orthogonal, since both class templates and function templates would be supported. 
+My efforts to discuss this on the major C++ newsgroups have 
+met with arguments both against its practical usage and the justification
+that one can pass a function template to another template nested in a non-template 
+class. But of course we can do the same thing with class templates, which is in fact
+what Boost MPL does to pass templates as metadata, yet we still have template template 
+parameters as class templates.
+
+Nonetheless the fact that we can pass class templates as a template parameter but not
+function templates as a template parameter is the major factor why there is no really good
+method for introspecting function templates at compile time.
+
+[heading Instantiating a nested function template]
+
+There is, however, an alternate but less certain way of introspecting a function template.
+I will endeavor to explain why this way is not currently included in the TTI library, 
+but first I will explain what it is.
+
+It is possible to check whether some particular instantiation of a nested function 
+template exists at compile-time without generating a compiler error. While this does
+not prove that the nested function template does not exist, since the instantiation itself may be 
+incorrect and fail even when the nested function template exists, it provides a partially
+flawed means of checking.
+
+The code to do this for member function templates looks like this 
+( similar code also exists for static member function templates ):
+
+  template
+    <
+    class C,
+    class T
+    > 
+  struct TestFunctionTemplate
+    {
+    typedef char Bad;
+    struct Good { char x[2]; };
+    template<T> struct helper;
+    template<class U> static Good check(helper<&U::template SomeFuncTemplateName<int,long,double> > *);
+    template<class U> static Bad check(...);
+    static const bool value=sizeof(check<C>(0))==sizeof(Good);
+    };
+    
+where 'SomeFuncTemplateName' is the name of the nested function template, 
+followed by some parameters to instantiate it. The 'class T' is the 
+type of the instantiated member function template as a member function, and 
+'class C' is the type of the enclosing class.
+
+As an example if we had:
+
+  struct AType 
+    {
+    template<class X,class Y,class Z> double SomeFuncTemplateName(X,Y *,Z &) { return 0.0; }
+    };
+    
+then instantiating the above template with:
+
+  TestFunctionTemplate
+    <
+    AType,
+    double (AType::*)(int,long *,double &)
+    >
+    
+would provide a compile-time boolean value which would tell us whether the 
+nested member function template exists for the particular instantiation 
+provided above. Furthermore, through the use of a macro, the TTI library
+could provide the means for specifying the name of the nested member function
+template ('SomeFuncTemplateName' above) and its set of instantiated 
+parameters ('int,long,double' above) for generating the template.
+
+So why does not the TTI library not provide at least this much functionality for 
+introspecting member function templates, even if it represents a partially flawed
+way of doing so ? 
+
+The reason is stunningly disappointing. Although the above code is perfectly correct C++ 
+code ( 'clang' works correctly ), two of the major C++ compilers, in all of their different 
+releases, can not handle the above code correctly. Both gcc ( g++ ) and Visual C++ incorrectly 
+choose the wrong 'check' function even when the correct 'check' function applies ( Comeau C++
+also fails but I am less concerned about that compiler since it is not used nearly as much as 
+the other two ). All my attempts at alternatives to the above code have also failed. The problems 
+with both compilers, in this regard, can be seen more easily with this snippet:
+
+  struct AType
+   {
+   template<class AA> void SomeFuncTemplate() { }
+   };
+   
+  template<class T>
+  struct Test
+   {
+   template<T> struct helper;
+   template<class U> static void check(helper<&U::template SomeFuncTemplate<int> > *) { }
+   };
+
+  int main()
+    {
+    Test< void (AType::*)() >::check<AType>(0);
+    return 0;
+    }
+    
+Both compilers report compile errors with this perfectly correct code,
+
+gcc: 
+
+  error: no matching function for call to 'Test<void (AType::*)()>::check(int)'
+
+and msvc:
+
+  error C2770: invalid explicit template argument(s) for 'void Test<T>::check(Test<T>::helper<&U::SomeFuncTemplate<int>> *)'
+
+There is a workaround for these compiler problems, which is to hardcode the name
+of the enclosing class, via a macro, in the generated template rather than pass it as a 
+template type. In that case both compilers can handle both the member function code and 
+the code snippet above correctly. In essence, when the line:
+
+   template<class U> static void check(helper<&U::template SomeFuncTemplate<int> > *) { }
+   
+gets replaced by:
+
+   template<class U> static void check(helper<&AType::template SomeFuncTemplate<int> > *) { }
+
+both gcc and Visual C++ work correctly. The same goes for the 'check' line in the 
+'TestFunctionTemplate' above.
+
+But the workaround destroys one of the basic tenets of the TTI library, which is that 
+the enclosing class be passed as a template parameter, especially as the enclosing class 
+need not actually exist ( see `BOOST_TTI_MEMBER_TYPE` and the previous discussion of 'Nested Types' ), 
+without producing a compiler error. So I have decided not to implement even this methodology to 
+introspect nested function templates in the TTI library.
+
+[endsect]