Thread: Metaprogramming Issue

You can't do that, for quite a number of reasons.

First, I'm getting a headache just trying to think my head around the possibilities. I'm pretty sure that qualifies as a reason

Second, to the compiler, Y is merely a nested type specifier. It might be a typedef. And if it's a typedef, you've got two problems. First, it may not actually be dependent (that is, Y is the same no matter what T is) and the specialization is moot. Second, it may be ambiguous, because if the T of the original template could be int, and any number of X instantiations and specializations may have typedef'd Y to int.

Third, the effort for the compiler is not justified. It would actually have to instantiate X with every possible type to see if the nested Y fits the one it has.

And fourth, the whole thing is quite impossible, because of reason #3. You can't know every possible type, because there's an infinite set of them.

You may say, well, at least it could work for actual inner types of X, say:

Code:

W< X<int>::Y > w;

Clearly, T is int, there, right?

Not right. I'll show you a pathological case where even this is ambiguous, but first let me rewrite your code to give the various template parameters distinctive names.

Code:

template<typename WT> struct W {...};
template<typename XT> struct X {
    ...
    struct Y {...};
};
template<typename WXT> struct W<typename X<WXT>::Y> {...};

Now we can talk more easily.

So, you have the above code:

Code:

W< X<int>::Y > w;

Here, WT is X<int>::Y, so XT is int, so the W specialization should be used with WXT deduced to int, right? But remember, X can be specialized too. Consider this specialization:

Code:

template <>
struct X<short>
{
  typedef X<int>::Y Y;
};

Ah, now X<short>::Y and X<int>::Y are the same. What should WXT be now, short or int?

For that matter, X<user_defined_type_that_just_happens_to_be_here>: :Y is a typedef for X<int>::Y too.


By the way, this is the same reason why template argument deduction of function templates doesn't work in similar cases:

Code:

template <typename T>
void foo(X<T>::Y y); // T must always be explicitly specified

Iterator traits aren't specialized for "any type called iterator that is a member of something". std::iterator_traits looks like this:

Code:

template <typename It>
struct iterator_traits
{
  typedef typename It::category category;
  typedef typename It::value_type value_type;
  typedef typename It::difference_type difference_type;
  typedef typename It::pointer pointer;
  // ...
};

template <typename T>
struct iterator_traits<T *>
{
  typedef random_access_tag category;
  typedef T value_type;
  typedef ptrdiff_t difference_type;
  typedef T *pointer;
  typedef T &reference;
  // ...
};

As you can see, the only specialization is for pointers. All other types either have the nested typedefs for iterator_traits to copy, or they fully specialize iterator_traits themselves. (But note that applications may not partially specialize iterator_traits.)

But what if the compiler forcefully instances a new Y type for every X.

What do you mean?

I can through the T::* work-around

No, you still can't distinguish between a genuine struct and a typedef for a struct.

What specific application do you have in mind?

Boost's type_traits have an is_primitive metafunction.

You definitely should look at type_traits, enable_if and MPL, all from Boost, if you're doing any metaprogramming.