Каковы основные различия между ANSI C и K&R C?

Здесь может возникнуть некоторая путаница относительно того, что такое "K&R C". Этот термин относится к языку, описанному в первом издании "The C Programming Language." грубо говоря: входной язык компилятора Bell Labs C около 1978 года.

Керниган и Ричи были вовлечены в процесс стандартизации ANSI. Диалект "ANSI C" заменил "K&R C" , и последующие издания "The C Programming Language" приняли ANSI конвенций. "K&R C " - это "dead language,", за исключением того, что некоторые компиляторы все еще принимают устаревший код.

Прототипы функций были наиболее очевидным изменением между K&R C и C89, но было много других. Также много важной работы было проделано по стандартизации библиотеки C. Несмотря на то, что стандартная библиотека C является кодификацией существующей практики, она кодифицирует множество существующих практик, что делает ее более сложной. P.J. Книга плаугера, стандартная библиотека C , является отличным справочником, а также рассказывает о некоторых деталях behind-the-scenes, почему библиотека оказалась такой, какой она была.

Стандарт C ANSI/ISO очень похож на K&R C в большинстве случаев. Предполагалось, что большая часть существующего кода C будет построена на компиляторах ANSI без особых изменений. Но самое главное, что в доиндустриальную эпоху семантика языка была открыта для интерпретации каждым поставщиком компиляторов. ANSI C ввел общее описание семантики языка, которое поставило всех компиляторов в равные условия. Сейчас, спустя 20 лет, это легко принять как должное, но это было значительным достижением.

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

Есть некоторые незначительные различия, но я думаю, что более поздние издания K&R предназначены для ANSI C, так что реальной разницы больше нет.
"C Classic" за неимением лучшего термина имел несколько иной способ определения функций, т. е.

int f( p, q, r )  
int p, float q, double r;  
{  
    // Code goes here  
}

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

1. прототип функции.
2. постоянные & летучие квалификаторы.
3. широкая поддержка символов и интернационализация.
4. разрешение на указатель на функцию, чтобы быть использованы без разыменования.

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

f(x)
{
    return x + 1;
}

и

int f(x)
int x;
{
    return x + 1;
}

они идентичны.

• FUNCTION PROTOTYPING:ANSI C использует метод прототипа функции c++, где определение и объявление функции включают имена функций, аргументы t, типы данных и возвращаемые значения данных types.function прототип позволяет ANSI ccompilers проверять вызов функции в пользовательской программе, которая передает недопустимый номер номер аргумента или несовместимые данные аргумента types.these исправить главную слабость вызова K&R C compilers:invalid в пользовательской программе часто проходит компиляцию, но вызывает сбой программы при их выполнении

Разница:

1. Прототип
2. широкая поддержка персонажей и интернационализация
3. Поддержка ключевых слов const и volatile
4. разрешить использование указателей функций в качестве разыменования

Основные различия между ANSI C и K&R C заключаются в следующем:

• прототипирование функций
• поддержка классификаторов типов данных const и volatile
• поддержка широких символов и интернационализации
• разрешить использование указателей функций без разыменования

ANSI C использует метод прототипа функции c++, где определение и объявление функции включают имена функций, типы данных аргументов и типы данных возвращаемого значения. Прототип функции позволяет компилятору ANSI C проверять наличие вызовов функций в пользовательских программах, передающих недопустимое число аргументов или несовместимые типы данных аргументов. Они исправляют основные недостатки компилятора K&R C.

Пример: to объявляет функцию foo и требует, чтобы foo принимал два аргумента

 unsigned long foo (char* fmt, double data)
 {
      /*body of foo */
 }

Самое большое различие, я думаю, заключается в прототипировании функций и синтаксисе описания типов аргументов функций.

Главное отличие, о котором еще никто не упоминал, состоит в том, что до ANSI, C определялось в основном прецедентом, а не спецификацией; в тех случаях, когда определенные операции имели бы предсказуемые последствия на одних платформах, но не на других (например, использование реляционных операторов на двух несвязанных указателях), прецедент настоятельно рекомендовал предоставить программисту гарантии платформы. Например:

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

2. На платформах, где естественное средство проверки того, является ли один указатель "greater than" другим, никогда не имеет никакого побочного эффекта, кроме получения истинного или ложного значения, применение операторов отношения к произвольным указателям может также полагаться на то, что никогда не будет иметь никаких побочных эффектов, кроме получения истинного или ложного значения.

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

4. На платформах с двумя дополнениями, где целочисленные переполнения естественным образом оборачиваются беззвучно, можно полагаться на то, что операция, включающая беззнаковое значение меньше "int", будет вести себя так, как если бы значение было беззнаковым в тех случаях , когда результат был бы между INT_MAX+1u и UINT_MAX , и он не был бы повышен до большего типа , не использовался бы в качестве левого операнда >>, ни в качестве операнда /, % или любого оператора сравнения. Кстати, обоснование стандарта дает это в качестве одной из причин, по которым малые неподписанные типы продвигаются к подписанным .

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

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

2. Стандарт требовал только, чтобы реализации были способны запускать одну, возможно, надуманную программу без переполнения стека, и признавал, что в то время как тупая реализация может рассматривать любую другую программу как вызывающую неопределенное поведение, но не думал, что стоит беспокоиться о тупых компиляторах, пишущих реализации, которые были "conforming", но бесполезны.

Хотя "C89" был интерпретирован одновременно как означающий "язык, определенный C89, плюс любые дополнительные функции и гарантии, предоставляемые платформой", авторы gcc продвигали интерпретацию, которая исключает любые функции и гарантии, выходящие за рамки тех, которые предписаны C89.

Несмотря на все претензии к contary K&R был и вполне способен обеспечить любой вид материала от низкого уровня до аппаратного обеспечения сверху. Теперь проблема состоит в том, чтобы найти компилятор (желательно бесплатный), который может дать чистую компиляцию на пару миллионов строк K&R C без необходимости возиться с ним. И работает на чем-то вроде многоядерного процессора AMD.

Насколько я могу видеть, посмотрев на источник серии GCC 4.x.x, нет простого взлома, чтобы повторно активировать-традиционную и-cpp-традиционную функциональность лага к их предыдущему рабочему состоянию без большей эффективности, чем я готов поставить. И проще построить компилятор K&R pre-ansi с нуля.