Inheriting typedefs? [duplicate]

Question

I've been confused recently by a few code examples -- sometimes it seems that inheriting typedefs exposed by a base class works, and sometimes it seems that it doesn't.

My questions are

• Why doesn't it always work?
• What are the situations that it will / won't work?
• What are the good workarounds when it doesn't work?

Here's some specific code:

// First example: Inheriting `static const int ...`
// Basic TypeList object
template<typename... Ts>
struct TypeList {
    static const int size = sizeof...(Ts);
};

// Repeat metafunction
template<typename T>
struct repeat;

template<typename... Ts>
struct repeat<TypeList<Ts...>> : TypeList<Ts..., Ts...> {};

// Checks
typedef TypeList<int, float, char> MyList;

static_assert(MyList::size == 3, "D:");
static_assert(repeat<MyList>::size == 6, "D:");


// Second example: Inheriting typedefs
// Meta function to compute a bundle of types
template <typename T>
struct FuncPtrTypes {
    typedef int result_type;
    typedef T input_type;
    typedef result_type(*func_ptr_type)(input_type);
};


// template <typename T, typename FuncPtrTypes<T>::func_ptr_type me>
// struct FuncPtr : FuncPtrTypes<T> {
//     static result_type apply(input_type i) {
//         return me(i);
//     }
// };
//
// Doesn't compile (?): clang 3.6:
// main.cpp:34:9: error: unknown type name 'result_type'
//         static result_type apply(input_type i) {
//                ^
// main.cpp:34:27: error: unknown type name 'input_type'
//         static result_type apply(input_type i) {
//                                  ^
//
// g++ 4.8.4:
// main.cpp:34:9: error: ‘result_type’ does not name a type
//   static result_type apply(input_type i) {
//          ^
// main.cpp:34:9: note: (perhaps ‘typename FuncPtrTypes<T>::result_type’ was intended)


// This compiles but is clumsy:

template <typename T, typename FuncPtrTypes<T>::func_ptr_type me>
struct FuncPtr {
    typedef typename FuncPtrTypes<T>::input_type input_type;
    typedef typename FuncPtrTypes<T>::result_type result_type;

    static result_type apply(input_type i) {
        return me(i);
    }
};


// A non-template example:
struct foo {
    typedef int bar;
};

struct baz : foo {};

typedef baz::bar bazbar;
// ^ This compiles... huh??

int main() {}

Gragg

They don't "work" if the base class is dependent on a template-parameter of the derived class, because the base class scope isn't searched from the point of definition of the derived class. It can't be searched, because you could still specialize the base class template after defining the derived class template. – Palmy

dyp: I thought that none of it was actually instantiated though until all of parameters are available? Humm so it has to resolve all these types that I use at the point of definition of the derived class? – Gragg

@ChrisBeck: There are 2 passes to check validity in template. A first one with non-dependent code, and a second one for dependent code. result_type as-is is a non-dependent code and an unknown type. – Fatshan

A syntactically elegant solution is the equivalent of replacing member functions with free functions: template<typename T> using input_type_t = typename T::input_type; Then you can write using base = FuncPtrTypes<T>; using input_type = input_type_t<base>; etc. – Palmy

Answer 1

We can simplify your failing example down to:

template <typename T>
struct Base { using type = T; };


template <typename T>
struct Derived : Base<T>
{
    type mem; // error: 'type' does not name a type
};

The issue is that type here is a dependent name. It depends on T. There is no guarantee that for a given T there isn't some specialization of Base<T> which does not name type. As such, base templates of class templates are not part of the standard name lookup, so you have to qualify it:

Base<T>::type mem;

Although now we run afoul of the rule which indicates that dependent names are not assumed to be types unless explicitly states as such, so you need:

typename Base<T>::type mem;

None of the other cases presented in the OP rely upon unqualified lookup of a dependent name.

To return to the specific problem, this doesn't compile:

static result_type apply(input_type i) {

because result_type and input_type are dependent types and so must be qualified and prefixed with typename:

static typename FuncPtrTypes<T>::result_type apply(typename FuncPtrTypes<T>::input_type i) {

Or, if you prefer, you can simply bring both names in with a using-declaration:

 using typename FuncPtrTypes<T>::input_type;
 using typename FuncPtrTypes<T>::result_type;

 static result_type apply(input_type i) {

Rumanian

"There is no guarantee that for a given T there isn't some specialization of Base<T> which does not name type." Could you elaborate on this? What do you mean when you say Base<T> "does not name" a type? Could you give a simple example? – Yttrium

@Yttrium template <> struct Base<int> { }; – Rumanian

So wouldn't Base<int>::type just be int in that case? And wouldn't it still be true that Derived<T>::type would be T in all cases? I guess what I'm wondering is why the compiler can't simply infer that Derived<T>::type is the same as Base<T>::type for all T. – Yttrium

@Yttrium No, there's no Base<int>::type - there's nothing in between the braces there. – Rumanian

I see. Suppose there are very many types (and possibly values, methods, etc.) from the base class that I want to use in the sub-class. It can be tedious to qualify these names every or even to have so many using declarations (and more might need to be added if the base class were changed). Is there a simpler way to indicate that all names from the parent class should also be used in the sub-class? – Yttrium

Answer 2

The code below will compile:

template <typename T, typename FuncPtrTypes<T>::func_ptr_type me>
 struct FuncPtr : FuncPtrTypes<T> {
     static typename FuncPtrTypes<T>::result_type apply(typename FuncPtrTypes<T>::input_type i) {
         return me(i);
     }
 };

The problem is basically that c++ templates have a two phased lookup during compilation. The first phase is a syntactical lookup, while the second phase performs the compilation in terms of the actual type.

To expand further:

The problem is that result_type might be either a global symbol or inherited, and during the first phase of lookup it is assumed that it is global, as the type that is dependent on T is not parsed/evaluated at that stage/phase of compilation.

See: where typenames are required

Another possible solution to your problem, is to use traits (e.g):

template <class T>
struct FuncPtrTraits
{
  typedef int result_type;
  typedef T input_type;
  typedef result_type(*func_ptr_type)(input_type);
};

 template <typename T, typename TraitsT = FuncPtrTraits<T> >
 struct FuncPtr
     static typename TraitsT::result_type apply(typename TraitsT::input_type i) {
         return me(i);
     }
 };

When designed correctly traits can help one modify code from the outside, and also partially, when you inherit from the base trait type.

Wintergreen

this isn't really what I was looking for, for instance the above will still compile even if the inheritance is removed, so you aren't really using inheritance here. but it still might be the best answer – Gragg

I've made a mod. I'm using traits instead of inheritance. Traits at least impose a convention on type T. You'll notice I've removed the inheritance, albeit after the fact. – Wintergreen

This does work well with inheritance, and it solved my problem. Thanks. – Psych