Шаблон в шаблоне: почему «››» должен быть «› ›» в списке аргументов вложенного шаблона

Иногда вы хотите, чтобы это было >>. Рассмотреть возможность

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

В С++ 03 это успешно анализирует и создает массив размером 256.

Это никогда не будет двусмысленным. Это подтверждается тем фактом, что в C++0x вам больше не нужно писать пробел между закрывающими шаблонами >.

Дело в том, что компиляторы предпочли бы токенизировать ввод как можно более независимо от контекста. Поскольку C++ в любом случае не является контекстно-независимым языком, добавление только этого специального случая не сделает ситуацию особенно сложной.

В текущем стандарте токенизация является жадной, поэтому >> будет обрабатываться как одиночный токен, точно так же, как a +++ b будет анализироваться как a ++ + b. Это изменил и новый стандарт. Хотя это требует дополнительной работы от разработчиков компилятора, было сочтено, что в целом оно того стоит (и в любом случае некоторые крупные компиляторы уже реализуют это как расширение).

C++ действительно невероятно сложно анализировать — гораздо сложнее, чем большинство других языков. Это очень последовательный язык, но между токенизацией ввода и пониманием грамматического анализа синтаксиса проделывается так много работы, что вещи, которые кажутся простыми для компилятора, часто НЕ являются таковыми.

Исторический оператор ">>" является оператором. Он «идентифицируется», так как исходный файл разбит на токены. Затем эти токены «понимаются» в некотором контексте во время грамматического анализа (спустя долгое время после завершения токенизации).

Если вы выполнили грамматический анализ во время токенизации, то у вас есть «подсказки», помогающие различать, что «>>» следует рассматривать как два замыкания объявления (или определения) шаблона. Тем не менее, исторически исторические компиляторы C++ работают иначе. (Новые компиляторы делают больше обратной связи между грамматическим анализом и токенизацией, включая больше «упреждающих действий», чтобы помочь разрешить эти неоднозначности.)

Да, новый стандарт С++ 0x меняет это и заставляет поставщиков компиляторов переписывать свои реализации, чтобы устранить неоднозначность «>>» в вашем случае. Таким образом, это никогда не будет двусмысленным в будущем. Однако старые компиляторы C++ не могут с этим справиться, поэтому на данный момент можно считать "хорошей практикой" поддерживать совместимость вашего кода с пробелом между символами '>'.

Чтобы избежать этой ошибки, установите соответствующий диалект C++. Например, с gcc 4.9 следующий файл не компилируется с g++:

#include <vector>
#include <utility>

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

Перейдем к сути вещей:

#include <iostream>

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

Скомпилированный всего с g++ test.cpp этот код выводит 199711. Хотя gcc 4.9 был выпущен в 2014 году, диалектом C++ по умолчанию является C++98 с расширениями GNU. C++98 требует, чтобы мы написали vector<pair<int, int> >. Если вам больше нравится vector<pair<int, int>>, компилируйте с -std=c++11 или -std=gnu++11.

Это зависит от компилятора. Visual Studio не требует этого, т.е. оба работают, в то время как g++ выдает ошибку. Я думаю, что это зависит от реализации компилятора.

Синтаксис потока

cin >> var;

Vs

Синтаксис вложенного шаблона

For<Bar<Barz>>

Первая фаза компилятора, лексический анализатор не сможет распознать.

У меня была эта проблема с программированием класса на С++, и я решил ее, выполнив следующие действия:

Строка, вызвавшая ту же ошибку, упомянутую здесь ранее:

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

Строка, прошедшая через кросс-компилятор GCC и сработавшая:

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

Для меня это была просто ошибка в интерпретации высказывания.