Template within template: why "`>>' should be `> >' within a nested template argument list"

I know that when we are using template inside another template, we should write it like this:

vector<pair<int,int> > s;

and if we write it without the whitespace:

vector<pair<int,int>> s;

we will get an error:

> `>>' should be `> >' within a nested template argument list

I see this is understandable, but I just can't help but wondering, in which cases will this be really ambiguous?

Sometimes you want it to be >>. Consider

boost::array<int, 1024>>2> x;

In C++03 this successfully parses and creates an array of size 256.

It won't ever be ambiguous. This is proven by the fact that in C++0x you don't have to write a space between closing template >s any more.

The thing is that the compilers would prefer to tokenize the input as context-independently as possible. Since C++ is not a context independent language anyway, adding just this one special case isn't going to make things particularly harder.

In the current standard, tokenization is greedy, so >> will be processed as a single token, in the same way that a +++ b will be parsed as a ++ + b. This has changed and the new standard. While it requires more work from the compiler implementors, it was deemed that overall it is worth it (and some major compilers already implement that as an extension anyway).

C++ is really incredibly hard to parse -- much more difficult than most other languages. It is a very consistent language, but so much work is done between tokenizing the input and understanding the grammatical analysis of the syntax, that things that seem like they should be simple for a compiler, often are NOT.

The historical ">>" operator is an operator. It is "identified" as the source file is broken into tokens. Those tokens are then later "understood" in some context during grammatical analysis (long after tokenization is complete).

If you did grammatical analysis while you tokenized, then you have "helps" to assist in the distinction that ">>" should be considered as two closures to a template declaration (or definition). Yet, this is historically not how historical C++ compilers work. (New compilers do more feedback between grammatical analysis and tokenization, including more "look-aheads" to help resolve these ambiguities.)

Yes, the new C++0x standard changes that, and forces compiler vendors to re-write their implementations to disambiguate ">>" in your case. So, it will never be ambiguous going forward. However, older C++ compilers cannot handle that, so it may be considered "good practice" to keep your code compatible with the space between the '>' characters for now.

Avoid this error by setting an appropriate C++ dialect. For example, with gcc 4.9 the following file does not compile with g++:

#include <vector>
#include <utility>

int main()
{
    using namespace std;
    vector<pair<int, int>> v; // compile error!
    return 0;
}

Let's get to the bottom of things:

#include <iostream>

int main()
{
    std::cout << __cplusplus << std::endl;
    return 0;
}

Compiled with just g++ test.cpp this code prints 199711. Although gcc 4.9 was released in 2014 the default C++ dialect is C++98 with GNU extensions. C++98 requires us to write vector<pair<int, int> >. If you like vector<pair<int, int>> more compile with -std=c++11 or -std=gnu++11.

It depends on the compiler. Visual Studio does not mandate this i.e. both works while g++ produces an error. I think that this depends on the compiler implementation.

I had this issue programing a class in c++, and i solved it by doing the following:

Line that produced the same error mentioned here before:

findAndDrawContoursFrame(cv::Mat&,cv::Mat&,std::vector<std::vector<cv::Point»&);

Line that passed through GCC Cross Compiler and Worked:

findAndDrawContoursFrame(cv::Mat&,cv::Mat&,std::vector< std::vector<cv::Point> >&);

For me it was just an error on the interpretation of the statement.

> Stream Syntax

cin >> var;

Vs

> Nested Template Syntax

For<Bar<Barz>>

First phase of Compiler, lexical analyser will not be able to recognise.