синтаксис — есть приоритет оператора C / C ++ & amp; правила ассоциативности когда-либо нарушались?
Являются приоритет оператора & правила ассоциативности когда-либо нарушалось в любом выражении C / C ++?
Если да, можете ли вы привести пример?
Предположим, что правила приоритета и ассоциативности:
Каждый оператор имеет заданный уровень приоритета, а каждый уровень приоритета имеет заданную ассоциативность. Если подвыражение замечено двумя операторами, где они ожидают операнд, оно принадлежит тому с более высоким приоритетом. Связи нарушены ассоциативностью.
Редактировать: Фон
Стандарт определяет выражения C / C ++ как CFG, который намного более гибок, чем синтаксический анализатор, основанный на приоритетах. Например, было бы возможно дать бинарным операторам асимметричный «приоритет», который сделал бы любой неверная таблица приоритетов. Тем не менее, мне кажется, что дизайн грамматики был ограничен для соблюдения простых правил приоритета. Вот некоторые предполагаемые «контрпримеры», с которыми я сталкивался:
1) a?b,c:d не интерпретируется как (a?b),(c:d)
Некоторые утверждают, что ?: Оператор имеет другой приоритет по отношению к своему среднему операнду, чем к другим операндам, потому что a?b,c:d, например, не интерпретируется как (a?b),(c:d), Тем не менее, ни b ни c занимает положение, в котором он, кажется, ?: как его внутренний операнд. По этим рассуждениям a[b+c] следует интерпретировать как (a[b)+(c]), что смешно.
2) sizeof(int)*a интерпретируется как (sizeof(int))*a скорее, чем sizeof((int)(*a))
… потому что C запрещает приведенный в скобках приведение как оператор sizeof. Однако обе эти интерпретации соответствуют правилам предшествования. Путаница исходит от * Неоднозначность оператора (это бинарный или унарный оператор?). Таблицы приоритетов не предназначены для разрешения неоднозначностей операторов. В конце концов, они не операторусловное обозначение-таблицы приоритетов. Итак оператор Сами правила приоритета не повреждены.
3) a+b=c приводит к синтаксической ошибке, а не к семантической ошибке
a+b=c, согласно стандарту, является недействительным C синтаксис. Если бы у C был парсер на основе приоритетов, он был бы пойман только на семантический уровень. В С так бывает, что любое выражение, которое не является Унарное выражение не может быть l-значным. Таким образом, эти семантически обреченные выражения LHS не должны быть синтаксически согласованы. Это не имеет никакого значения для языка в целом, и таблицы приоритетов не должны быть в бизнесе предсказания синтаксичности / синтаксичности ошибки, которая будет результатом выражения.
Решение
Для одного примера обычная таблица приоритетов говорит, что sizeof и приведенные выражения имеют одинаковый приоритет. И таблица, и стандарт говорят, что они ассоциируются справа налево.
Это упрощение хорошо, когда вы смотрите, скажем, *&foo, что означает так же, как *(&foo),
Это может также предложить вам, что sizeof (int) 1 является законным C ++, и это означает то же самое, что sizeof( (int) 1 ), Но это не законно, потому что на самом деле sizeof( type-id ) это особая вещь в грамматике. Его существование мешает sizeof (int) 1 быть sizeof выражение, операндом которого является приведение-выражение, операндом которого является 1,
Так что я думаю, что вы могли бы сказать, что «sizeof ( тип-идентификатор ) «производство в грамматике C ++ является исключением из того, что говорят обычные таблицы приоритетов / ассоциативности. Они делать точно опишите «sizeof» Унарное выражение«производство.
Другие решения
Это зависит от того, правильны ли «правила». Определение языка не говорит о приоритете, поэтому таблицы приоритетов, которые вы видите в разных местах, могут отражать или не отражать то, что фактически требует определение языка.
Пока кто-то не сможет найти контрпример, я буду выдвигать это как ответ по умолчанию:
Нет, правила приоритета и ассоциативности C / C ++ никогда не нарушаются.