Здравствуйте, Nick_, Вы писали:

N_>OK. Обьясняю еще раз. на этот раз разжовываю как совсем чайнику.
N_>Берем стандарт С++. Читаем Appendix A: Grammar summary

N_>Компилятор разбирает выражение (hello.... перед ним стоит открывающая скобка.

Ну, это 100%-ный вызов функции.

N_>Дальше он может идти по одному из двух путей

N_>Если hello — тип:
N_>expression->...->cast-expression->(->type-id->...->type-name->hello.
N_>Если hello — идентификатор(переменная):
N_>expression->...->cast-expression->...->primary-expression->(->expression->...->id-expression->hello.

Ты наверно имешь в виду двусмысленность в трактовании выражения в скобках идущее перед идентификатором или другими скобками.

Дык тут в станадрте должно быть написано, что имеет место двусмысленность (ambiguities). Под рукой плюсового стандарта нет, так что точную формулировку привести не могу.

Так вот, чтобы разрешить эту двусмысленность компилятору нужно провести семантический анализ и определить является ли выражение в скобках типом или нет. Ситуация вроде "(Type)id" решается и без анализа. Но "(Type)-id" уже двусмысленна.

Это нормально. И не в коем случае не противоречит моим словам. Синтаксический разбор при этом остается синтаксическим рабзбором, а семантический анализ — семантическим анализом который проходит исключительно после стадии синтаксического разбора (иначе как собственно установить, был ли вообще объевлян Type?). Просто С++ довольно древний язык и в нем используемый тип обязан быть объявлен (продекларирован) до его использования. В C#, например, все намного сложнее. В нем тип не обязан быть объявлен до использования. По этому для начала семантического анализа требуется полностью закончить стадию синтаксического разбора. Именно по этому в C# данная неодназначность (к сожалению повзаимствованная из С++) решается более топорно. В C# введены эвристические правила позволяющие трактовать выражение в скобках как приведение типов:

The grammar for a cast-expression leads to certain syntactic ambiguities. [Example: The expression (x)–y could either be interpreted as a cast-expression (a cast of –y to type x) or as an additive- ression combined with a parenthesized-expression (which computes the value x – y). end example] To resolve cast-expression ambiguities, the following rule exists: A sequence of one or more tokens (§9.4) sed in parentheses is considered the start of a cast-expression only if at least one of the following are true:
• The sequence of tokens is correct grammar for a type, but not for an expression.
• The sequence of tokens is correct grammar for a type, and the token immediately following the closing
parentheses is the token “~”, the token “!”, the token “(”, an identifier (§9.4.1), a literal (§9.4.4), or any 13
keyword (§9.4.3) except as and is.
The term “correct grammar” above means only that the sequence of tokens shall conform to the rticular grammatical production. It specifically does not consider the actual meaning of any ituent identifiers. [Example: If x and y are identifiers, then x.y is correct grammar for a type, even if x.y doesn’t actually denote a type. end example]
[Note: From the disambiguation rule, it follows that, if x and y are identifiers, (x)y, (x)(y), and (-y) are cast-expressions, but (x)-y is not, even if x identifies a type. However, if x is a keyword identifies a predefined type (such as int), then all four forms are cast-expressions (because such a

N_>Ну и как определить по какому пути делать синтаксический разбор, не зная hello тип или не тип?

Только проведением семантического анализа. Но он может быть проведен только для части кода разобранной с помощью синтаксического разбора.

N_>Еще в качестве примера могу привести приоритет операций.
N_> То, что умножение имеет более высокий приоритет чем сложение выясняется уже на этапе синтаксического анализа, а не семантического.

Это выясняется на этапе составления граматики языка. А парсер всего лишь отражает спецификацию. К семантике приоритеты не имеют ни малейшего отношения.

N_>После того как я тебе еще раз попытался разжевать, может ты потрудишься обьяснить что ты имел в виду в
N_>сообщении http://rsdn.ru/Forum/Message.aspx?mid=840770&only=1

Автор: VladD2
Дата: 06.10.04

когда заявил, что "Да пофигу для синтаксического разбора чем будет эта конструкция. Тип, не тип — это уже семантика."

В приведенном тобой примере никакой двусмысленности нет и семантический анализ не трелуется. Из контекста четко видно, чем должен быть идентификатор. Так что код будет спокойно распарсен в АСТ и кога пойдет воплощение шаблона просто будет проверено, что данный идинтификатор действительно существует и является типом. А для разрешения неоднозначностей как раз и был введен typename.