Почему C ++ не допускает определяемые пользователем операторы?

Question

Мне было интересно это довольно давно. Их уже целая куча, и они могут быть перегружены, так почему бы не сделать это до конца и разрешить создание пользовательских операторов? Я думаю, что это может быть отличным дополнением.

Мне сказали, что это сделает язык слишком сложным для компиляции. Это заставляет меня задуматься: C ++ не может быть действительно спроектирован для простой компиляции, так что это действительно невозможно отменить? Конечно, если вы используете парсер LR со статической таблицей и грамматикой, такой как

E → T + E | T
T → F * T | F
F → id | '(' E ')'

это не сработает. В Прологе, который обычно анализируется с помощью синтаксического анализатора «Оператор-приоритет» AFAIK, новые операторы можно легко определить, но язык намного проще. Теперь грамматику, очевидно, можно переписать так, чтобы она принимала identifiers в любом месте, где оператор жестко запрограммирован в грамматике.

Какие существуют другие решения и схемы синтаксического анализатора и что еще повлияло на это проектное решение?

Answer 1

http://www2.research.att.com/~bs/bs_faq2.html#overload-operator

Возможность рассматривалась несколько раз, но каждый раз, когда я / мы решали, что вероятные проблемы перевешивают возможные выгоды.

Это не язык-техническая проблема.Даже когда я впервые рассмотрел это в 1983 году, я знал, как это можно реализовать.Тем не менее, мой опыт показывает, что когда мы выходим за пределы самых тривиальных примеров, люди, похоже, имеют слегка отличающиеся мнения о «очевидном» значении использования оператора.Классический пример - a**b**c.Предположим, что ** означало возведение в степень.Теперь a**b**c означает (a**b)**c или a**(b**c)?Я думал, что ответ был очевиден, и мои друзья согласились - и затем мы обнаружили, что не сошлись во мнении, какая резолюция была очевидной.Я предполагаю, что такие проблемы могут привести к незначительным ошибкам.

Answer 2

Скомпилировать станет еще сложнее, чем то, что уже есть.Кроме того, могут возникнуть проблемы с приоритетом операторов: как вы его определяете?Вам нужен способ сообщить компилятору, что пользовательский оператор имеет приоритет над другим оператором.

Почти наверняка это выполнимо, но я думаю, что C ++ не нуждается в других способах съемкисебя в ногу: -)

Answer 3

Это сделает язык еще более сложным.И это, очевидно, было бы нежелательно.

Тем не менее, проверьте Boost Spirit .Это делает долгий путь, чтобы сделать вещи, о которых вы упоминали, возможно, используя множество приемов метапрограммирования шаблонов.

Answer 4

Я только что узнал, что на самом деле можно добиться чего-то очень похожего на перегруженные операторы.Рассмотрим

Vector v, a, b; v = a /vectorProduct/ b;

Оказывается, вы можете добиться поведения пользовательского оператора, используя фиктивные классы, разделенные существующими операторами.=)

Answer 5

Этого обычно избегают, потому что большая часть кода написана более чем одним человеком, поэтому код должен быть «рецензируемым», а это едва ли «желаемая» особенность языка.1003 * хорошая статья об этом.

Answer 6

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

Это сделало бы и без того сложный язык гораздо более сложным ...

Answer 7

На самом деле он разработан для того, чтобы его было легко анализировать и компилировать. C имеет 32 ключевых слова, все остальные токены являются функциями и переменными.

C ++ имеет только несколько больше. Можно легко определить, какой токен для какого, поэтому знайте, что нужно искать, когда кто-то использует токен + или что-то еще.