Search code examples
c++c++11templatesvisual-studio-2015typename

Why typename keyword is not needed in template dependent nested type names in VS2015?

I was reading about the usage of typename in C++ template programming (e.g. this Q/A). To me, it seems that when using a dependent nested type name, we should use typename for avoiding parsing ambiguity. I also checked this on Scot Meyers book effective C++, item #42.

But what is strange for me is that the same example in the book, works without the typename. Here is the code:

template<class C>
void Print2nd(const C & cont)
{
   if (cont.size() >= 2)
   {
      C::const_iterator * iter1 = new C::const_iterator(cont.begin());  // why typename is NOT needed?
      C::const_iterator   iter2 = cont.begin();                         // why typename is NOT needed?
      (*iter1)++;
      iter2++;
      int value1 = **iter1;
      int value2 = *iter2;

      std::cout << "The value of 2nd with pointer is: " << value1 << std::endl;
      std::cout << "The value of 2nd without pointer is: " << value2 << std::endl;
   }
}


int main()
{
   std::vector<int> vect = {1,2,3,4,5,6};
   Print2nd(vect);
   return 0;
}

I am using VS2015. So, the Q is that why typename is not needed in this context? Is there any upgrade in recent C++ compilers to avoid using typename in such a context? Or I am doing a mistake in the code?

Update 1: Thanks to @FrançoisAndrieux comment, it seems that the same thing is happening in VS2008 and VS2010, as reported in this Q/A.

Solution

  • In typename is not needed there. In some contexts, the need for typename was removed, because syntactically anything there must be a type.

    In particular:

    A qualified name that appears in type-id, where the smallest enclosing type-id is:

    • the type in a new expression that does not parenthesize its type;

    Quoted source isn't directly from the standard, but pretty reliable.

    Prior to typename was needed there; it would be parsed as a value, and new value is not valid syntax. In typename is optional in that context.

    Now, has no features in it; what you are seeing there is MSVC's failure to properly implement //, not a extension.