Our previous attempt to define a template non-type parameter that is
initialized by the compiler to the number of elements of an array failed
because the template's parameters are not implicitly deduced when a
constructor is called. Instead, they must explicitly be specified when an
object of the class template is defined. As the template arguments are
specified just before the template's constructor is called the compiler
doesn't have to deduce anything and it can simply use the explicitly specified
template arguments.

In contrast, when em(function) templates are used, the actual template
parameters are deduced from the arguments used when calling the function. This
opens up an alley leading to the solution of our problem. If the constructor
itself is turned into a function template (having its own template header),
then the compiler em(will) be able to deduce the non-type parameter's value
and there is no need anymore to specify it explicitly using a class template
non-type parameter.

Members (functions or nested classes) of class templates that are themselves
templates are called
        hi(member template)
        hi(class template: member template)
 em(member templates).

Member templates are defined as any other template, including its own template
header.

When converting our earlier tt(CirQue(Data const (&array)[Size])) constructor
into a member template the class template's tt(Data) type parameter can still
be used, but we must provide the member template with a non-type parameter of
its own. Its declaration in the (partially shown) class interface looks like
this:
        verb(    template <typename Data>
    class CirQue
    {
        public:
            template <size_t Size>
            explicit CirQue(Data const (&arr)[Size]);
    };)

Its implementation becomes:
    verbinclude(//MEMBER examples/cirque.h)
    The implementation uses the STL's tt(copy) algorithm and a
tt(back_inserter) adapter to insert the array's elements into the
tt(CirQue). To use the tt(back_inserter) tt(CirQue) must provide two (public)
using-declarations (cf. section ref(INSERTER)):
    verbinclude(//TYPEDEFS examples/cirque.h)

    Member templates have the following characteristics:
    itemization(
    it() Two tt(template)
            hi(template header: for member templates)
     headers must be used: the class template's tt(template)
header is specified first followed by the member template's template header;
    it() Normal access rules apply: the member template can be
used by programs to construct an tt(CirQue) object of a given data
type. As usual for class templates, the data type must be specified when the
object is constructed. To construct a tt(CirQue) object from the array
tt(int array[30]) we define:
        verb(CirQue<int> object(array);)

it() Any member can be defined as a member template, not just a
constructor;
    it() When a template member is implemented below its class interface, the
template class header must precede the function template header of the member
template;
    it() The implementation of the member template must specify its proper
scope.  The member template is defined as a member of the class tt(CirQue),
instantiated for the formal template parameter type tt(Data);
    it() The template parameter names in the declaration and
implementation must be identical;
    it() The member template should be defined inside its proper namespace
environment. The organization of files defining class templates within a
namespace should therefore be:
        verb(namespace SomeName
{
    template <typename Type, ...>   // class template definition
    class ClassName
    {
        ...
    };

    template <typename Type, ...>   // non-inline member definition(s)
    ClassName<Type, ...>::member(...)
    {
        ...
    }
}                                   // namespace closes)

)

    A potentially occurring problem remains. Assume that in addition to the
above member template a tt(CirQue<Data>::CirQue(Data const *data)) has been
defined. Some (here not further elaborated) protocol could be defined allowing
the constructor to determine the number of elements that should be stored in
the tt(CirQue) object. When we now define
        verb(    CirQue<int> object{ array };)

it is this latter constructor, rather than the member template, that the
compiler will use.

The compiler selects this latter constructor as it is a more specialized
version of a constructor of the class tt(CirQue) than the member template
(cf. section ref(FUNCTIONSELECTION)). Problems like these can be solved by
defining the constructor tt(CirQue(Data const *data)) into a member template
as well or by defining a constructor using two parameters, the second
parameter defining the number of elements to copy.

When using the former constructor (i.e., the member template) it must define a
template type parameter tt(Data2). Here `tt(Data)' cannot be used as template
parameters of a member template may not shadow
    hi(class template: shadowing parameters) template parameters of its
class. Using tt(Data2) instead of tt(Data) takes care of this subtlety. The
following declaration of the constructor tt(CirQue(Data2 const *)) could
appear in tt(CirQue)'s header file:
        verb(    template <typename Data>
    class CirQue
    {
        template <typename Data2>
        explicit CirQue(Data2 const *data);
    })

Here is how the two constructors are selected in code defining two
tt(CirQue) objects:
        verb(    int main()
    {
        int array[30];
        int *iPtr = array;

        CirQue<int> ac{ array };    // calls CirQue(Data const (&arr)[Size])
        CirQue<int> acPtr{ iPtr };  // calls CirQue(Data2 const *)
    })

