| [/ |
| (C) Copyright Edward Diener 2011 |
| Distributed under 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). |
| ] |
| |
| [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, which serves as a type. 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. Although checking if |
| some particular instantiation of a nested function template exists at compile-time does |
| not prove that the nested function template itself does or does not exist, |
| since the instantiation itself may be incorrect and fail even when the nested function |
| template exists, it provides a partial, if 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 C' is the type of |
| the enclosing class and the 'class T' is the type of the instantiated member |
| function template as a member function. |
| |
| 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] |