2016-09-25 4 views
2

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

  • long long (int)
  • short int
  • signed char

есть некоторые базовые знания о разборе и использовал Flex/бизонов инструментов, чтобы сделать несколько парсеров, и я думаю, что это принесет гораздо больше сложностей для разбора имен типов. И, глядя на грамматику C++ в стандарте, все о типах действительно сложно.

Я знаю, что C++ (и C, я считаю) не указывать много о размерах основных типов данных, что делает типы int_8, uint_8 и т.д. не будет работать (Altough C++ 11 дал нам fixed width integers).

Итак, почему разработчики стандарта согласились на идентификаторы многословного типа, когда они могли сделать int, uint и тому подобное.

+0

C++ имеет его, потому что он начинался как расширение C, которое имело его с самого начала (кроме 'long long', которое было введено на C99). Возможно, лучше перефразировать вопрос, применимый к C. –

+0

Он может либо сделать лексический анализатор более сложным, либо парсером, но не самой системой типов. И даже в этом случае синтаксический анализ не намного сложнее: парсер видит токен 'long', а затем проверяет следующий токен, как обычно. Это идентификатор? Звездочка? Другой «длинный» токен? Что-то еще действительное или недействительное? На самом деле ничего серьезного. –

+0

@JoachimPileborg C сложно разобрать, поскольку имена типов, а не простые маркеры типа, определяют структуру фразы. Если вы не берете строгое подмножество C, вы не можете по-настоящему разделить парсинг (например, деклараций) и интерпретацию (определения типов). –

ответ

5

Говоря о С, почему разработчики стандарта договорились о многословных идентификаторах? Это потому, что это был язык во время стандартизации.

Мандатом для первоначального стандарта было не создание нового языка, а кодифицировать существующую практику. В соответствии с самого стандарта C89:

Комитет оцениваемого много предложений для добавления, удаления и изменения базовых документов в ходе обсуждения. Были предприняты согласованные усилия по кодификации существующей практики везде, где можно было бы определить однозначную и последовательную практику. Однако в тех случаях, когда не может быть выявлена ​​непротиворечивая практика, Комитет работал над установлением четких правил, которые согласуются с общим вкусом языка.

И из обоснования документа C99:

оригинального X3J11 устав четко уполномочена кодификация общей существующей практики, и C89 Комитет провел быстро прецедент, где это было ясно и однозначно. Подавляющее большинство языков, определенных C89, было точно таким же, как определено в Приложении A первого выпуска языка программирования C Брайаном Керниганом и Деннисом Ритчи, и это было реализовано почти всеми переводчиками того времени.

Кроме того, каждая итерация стандарта имеет высокую ценность обратной совместимости, так что код не прерывается. Из этого же документа обоснования:

Существующий код важен, существующих реализаций нет. Большая часть кода C имеет значительную коммерческую ценность. Сделаны все попытки обеспечить, чтобы основная часть этого кода была приемлема для любой реализации, соответствующей Стандарту.Комитет C89 не хотел, чтобы большинство программистов модифицировали свои программы на С только для того, чтобы их приняли переводчик.

Таким образом, в то время как более поздние версии стандарта дали нам такие вещи, как stdint.h с его фиксированной шириной целыми типами, забирая стандартные, как int и long бы грубое нарушение этого руководства.


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

Это позволило бы оригинальному автору Bjarne свести к минимуму рабочую нагрузку при доставке C++, поскольку основная ее часть была предоставлена ​​самим компилятором C.


С точки зрения синтаксического анализа языка, это, безусловно, сложнее придется обрабатывать unsigned long int x(а) чем обрабатывать ulong x.

Но, учитывая, что компилятор уже должен обрабатывать большое количество необязательных «модификаторов/спецификаторов» для переменной (например, const char * const x), обработка нескольких других является номинальной для курса.


(а) Или int long unsigned x или long unsigned x или любого другого типа спецификаторы, что в конечном итоге становится сингулярной unsigned long intтипа. См. here для более подробной информации.

+1

Ну, есть также кое-что, что можно почерпнуть из [истории Ричи истории C] (https://www.bell-labs.com/usr/dmr/www/chist.html). Он описывает, что B получен из BCPL и вводит спецификаторы класса хранения ('auto',' static' и т. Д.) И что C добавляет к нему спецификаторы типа. Теперь вы можете иметь 'static int'; это спекуляция, но я могу себе представить, что это породило стиль, в котором нормально иметь более одного слова, описывающего «тип» переменной. –

+0

Я понимаю, почему это стандартизировано таким образом, но мне любопытно, почему это было на языке все время. Я предполагаю, что разработчики первого компилятора имели проблемы с разбором 'unsigned int', поэтому почему они не решили сразу использовать« uint »? – Zereges

+0

@ Zereges, вам нужно было бы спросить автора C, что, конечно, самые ранние версии, предстандартные, имели очень мало с точки зрения типов (int и char и указатели к ним были об этом, из памяти). К сожалению, dmr перетасовывает эту смертельную катушку, оставляя нас беднее для нее, поэтому мы можем только размышлять о том, что осталось (что на самом деле не так важно с точки зрения этого конкретного вопроса). – paxdiablo

0

Добавление новых зарезервированных слов на язык нарушит любой код, который используется для использования таких слов, как идентификаторы, если эти слова не имеют формы, которая зарезервирована для будущего расширения (например, содержат два ведущих подчеркивания или начинаются с подчеркивания и прописная буква и т. д.)

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

+0

Новые ключевые слова добавляются на языки (рассмотрите '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' ' , ...) – Zereges

+0

@Zereges 'auto' существует в C, он просто имеет совершенно другое значение. –

+0

@Zereges: Ключевые слова иногда добавляются в ломающиеся моды без особого оправдания ('ограничение', вероятно, самое худшее такое дополнение в C, поскольку оно было бы логическим именем идентификатора во многих контекстах и ​​почти наверняка использовалось как таковое до C99), но по большей части Комитет старается избегать идентификаторов, которые используются в коде пользователя. – supercat

Смежные вопросы