Самый неприятный разбор

Самый неприятный синтаксический анализ — это нелогичная форма разрешения синтаксической неоднозначности в языке программирования C++ . В определенных ситуациях грамматика C++ не может отличить создание объекта параметра от указания типа функции . В таких ситуациях компилятор должен интерпретировать строку как спецификацию типа функции.

возникновение

Термин «самый неприятный анализ» впервые был использован Скоттом Мейерсом в его книге «Эффективный STL» 2001 года . Хотя это явление необычно для C , оно было довольно распространено в C++ до появления единообразной инициализации в C++11 .

Примеры

Приведения в стиле C

Простой пример появляется, когда функциональное приведение предназначено для преобразования выражения для инициализации переменной:

void f(double my_dbl) {
  int i(int(my_dbl));
}

Строка 2 выше неоднозначна. Одна из возможных интерпретаций — объявить переменную i с начальным значением, полученным путем преобразования my_dbl к int. Однако C допускает использование лишних круглых скобок вокруг параметров функции объявлений ; в этом случае декларация i вместо этого является объявлением функции, эквивалентным следующему:

// A function named i takes an integer and returns an integer.
int i(int my_dbl);

Безымянный временный

Более подробный пример:

struct Timer {};

struct TimeKeeper {
  explicit TimeKeeper(Timer t);
  int get_time();
};

int main() {
  TimeKeeper time_keeper(Timer());
  return time_keeper.get_time();
}

Линия

  TimeKeeper time_keeper(Timer());

неоднозначно, поскольку его можно интерпретировать либо как

1. определение переменной для переменной time_keeper класса TimeKeeper, инициализированный анонимным экземпляром класса Timer или
2. для объявление функции функции time_keeper который возвращает объект типа TimeKeeper и имеет один (безымянный) параметр, тип которого является функцией (указатель на) не принимать никаких данных и возвращать Timer объекты.

Стандарт C++ требует второй интерпретации, которая несовместима с последующей строкой 10 выше. Например, Clang++ предупреждает, что самый неприятный анализ был применен в строке 9 и ошибки в последующей строке 10:

$ clang++ time_keeper.cc
timekeeper.cc:9:25: warning: parentheses were disambiguated as a function declaration
      [-Wvexing-parse]
  TimeKeeper time_keeper(Timer());
                        ^~~~~~~~~
timekeeper.cc:9:26: note: add a pair of parentheses to declare a variable
  TimeKeeper time_keeper(Timer());
                         ^
                         (      )
timekeeper.cc:10:21: error: member reference base type 'TimeKeeper (Timer (*)())' is not a
      structure or union
  return time_keeper.get_time();
         ~~~~~~~~~~~^~~~~~~~~

Решения

Требуемая интерпретация этих двусмысленных заявлений редко соответствует действительности. Типы функций в C++ обычно скрыты за определениями типов и обычно имеют явную ссылку или квалификатор указателя . Чтобы обеспечить альтернативную интерпретацию, типичным методом является другой синтаксис создания или преобразования объектов.

В примере преобразования типов для приведения доступны два альтернативных синтаксиса: «приведение в стиле C».

// declares a variable of type int
int i((int)my_dbl);

или именованный состав:

int i(static_cast<int>(my_dbl));

В примере объявления переменной предпочтительным методом (начиная с C++11) является унифицированная инициализация (фигурные скобки). Это также позволяет ограниченно полностью опускать имя типа:

//Any of the following work:
TimeKeeper time_keeper(Timer{});
TimeKeeper time_keeper{Timer()};
TimeKeeper time_keeper{Timer{}};
TimeKeeper time_keeper(     {});
TimeKeeper time_keeper{     {}};

До C++11 распространенными методами принудительной интерпретации было использование дополнительных круглых скобок или инициализация копирования:

TimeKeeper time_keeper( /*Avoid MVP*/ (Timer()) );
TimeKeeper time_keeper = TimeKeeper(Timer());

В последнем синтаксисе инициализация копирования , скорее всего, будет оптимизирована компилятором. Начиная с C++17 эта оптимизация гарантирована.

Внешние ссылки

• Обсуждение окончательного проекта стандарта C++03 (см. §8.2 Разрешение неоднозначности [dcl.ambig.res] ): https://web.archive.org/web/20141113085328/https://cs.nyu.edu/courses /fall11/CSCI-GA.2110-003/documents/c++2003std.pdf
• CppReference при прямой инициализации (вид, уязвимый для самого неприятного анализа): https://en.cppreference.com/w/cpp/language/direct_initialization. Архивировано 13 декабря 2021 г. на Wayback Machine.