Файл: История возникновения и развития языков для программирования Си (С++) и Java.pdf
Добавлен: 15.05.2023
Просмотров: 167
Скачиваний: 2
По правилам процесса стандартов текущая деятельность X3J11 ограничивается интерпретацией существующего стандарта. Однако неофициальная группа, первоначально созванная Rex Jaeschke в качестве NCEG (Numerical C Extensions Group), была официально принята в качестве подгруппы X3J11.1, и они продолжают рассматривать расширения для C. Как следует из названия, многие из этих возможных расширений предназначены для создания языка более подходящим для массового использования: например, многомерные массивы, границы которых динамически определены, включают средства для работы с арифметикой IEEE и делают язык более эффективным на машинах с векторными или другими передовыми архитектурными особенностями. Не все возможные расширения являются особенно численными; они включают обозначение для строковых литералов.
После этого развитие языка не останавливалось. Были созданы еще несколько стандартов С. В 1990 году ISO приняло ISO/IEC 9899:1990 (С90), хотя изменения были небольшими.
В 1995 году ISO опубликовала расширение ISO / IEC 9899 / AMD1: 1995 или C95. Помимо исправления ошибок были внесены дальнейшие изменения в языковые возможности, такие как: улучшенная многобайтная и широкая поддержка символов в стандартной библиотеке, введением wchar.h и wctype.h, а также многобайтовые ввод-вывод, добавление диграфов на язык, спецификация стандартных макросов для альтернативной спецификации операторов, спецификация стандартного макроса __STDC_VERSION__.
В марте 2000 года ANSI приняла стандарт ISO / IEC 9899: 1999. Этот стандарт обычно называется C99. Некоторые примечательные дополнения к предыдущему стандарту включают: Новые встроенные типы данных: _Bool, long long , _Complex _Imaginary; Несколько новых функций основного языка, включая индексы статического массива, назначенные инициализаторы, сложные литералы, массивы переменной длины, гибкие члены массива, переменные макросы и ограничение ключевого слова; Несколько новых заголовков библиотек, включая stdint.h, tgmath.h, fenv.h, complex.h; Улучшенная совместимость с несколькими функциями C ++, включая встроенные функции, однострочные комментарии с //, объявлениями смешивания и кодом, а также универсальные имена символов в идентификаторах.
В апреле 2011 года был опубликован C11. Новый стандарт прошел свой окончательный проект обзора 10 октября 2011 года. ISO официально ратифицировало и опубликовало стандарт 8 декабря 2011 года в соответствии с ISO / IEC 9899: 2011. Основными изменениями в спецификации языка C11 были: Спецификация выравнивания (_Alignas, _Alignof, aligned_alloc, stdalign.h); Спецификатор _Noreturn и заголовочный файл stdnoreturn.h; Типовые выражения, _Generic ключевое слово; Поддержка многопоточности; Улучшенная поддержка Unicode на основе отчета C Unicode ISO / IEC TR 19769: 2004; Удаление функции get, замена на gets_s; Интерфейсы проверки границ, возможности анализа, анонимные структуры и союзы и прочее.
2. Язык «C++»
В 1979 году Бьёрн Страуструп, датский компьютерный ученый, начал работу над «C с классами», предшественником C ++. Мотивация для создания нового языка возникла из опыта Страуструпа в программировании для его докторской.
Первая версия этого симулятора была написана в Simula и работала на мэйнфрейме IBM 360/165 в компьютерном центре Кембриджского университета. Особенности Simula были почти идеальными для этой цели. Концепт классов позволил напрямую сопоставить концепции приложений с языковыми конструкциями что сделало код более удобно читаемым. Классы Simula могут выступать в качестве со-подпрограмм. Иерархии классов использовались для выражения вариантов применения уровня. Однако использование иерархий классов не было тяжелым. Концепция класса Simula рассматривалась как ключевое различие, воспринимаемый контраст между жесткостью Паскаля и гибкостью Simula была необходима для развития C ++.
Однако реализация Simula не масштабировалась одинаково, и в результате весь проект приблизился к катастрофе. В то время вывод заключался в том, что реализация Simula (в отличие от языка Simula) была ориентирована на относительно небольшие программы и была по своей сути непригодна для более крупных программ. Время ссылки для отдельно скомпилированных классов были ужасны: потребовалось больше времени, чтобы скомпилировать программу и связать ее с предварительно скомпилированной версией остальных. Это больше проблема с компоновщиком мейнфреймов, чем с Simula, но это все еще мешало. Так же производительность во время выполнения была такой, что не было никакой надежды использовать симулятор для получения реальных данных. Эти проблемы были основополагающими для Simula и не могли быть исправлены.
Чтобы избежать завершения проекта, я повторно написал симулятор в BCPL и запустил его на экспериментальном компьютере CAP. Опыт кодирования и отладки симулятора в BCPL был ужасен. BCPL делает C похожим на язык очень высокого уровня и не обеспечивает абсолютно никакой проверки типа или поддержки во время выполнения. Полученный имитатор, однако, работал достаточно быстро и дал целое ряд полезных результатов, которые разъяснили мне многие вопросы и послужили основой для нескольких документов по вопросам операционной системы.
Смыслом C ++ было создание подходящего инструмента для таких проектов, как написания значительного симулятора, операционной системы и аналогичных задач системного программирования: Поддержка Simula для организации программы, то есть классы, с формой иерархии, формой поддержки параллелизма и сильной проверки системы типов на основе классов; Возможность создавать программы, которые выполнялись так же быстро, как программы BCPL, и были способны легко комбинировать отдельно скомпилированные единицы в программе; Обеспечение высокой переносимости реализаций. Самый важный аспект этих критерий являются то, что они слабо связаны с конкретными функциями языка программирования, они ограничивают решение проблем.
Работа над тем, что в конечном итоге стало C ++, началось с попытки анализа ядра UNIX чтобы определить, в какой степени он может быть распределен по локальной сети. Началась она в апреле 1979 года. Вскоре появились две проблемы: как проанализировать сетевой трафик, который будет получен из дистрибутива ядра, и как модулировать ядро. Оба потребовали способ выразить структуру модуля сложной системы и схемы связи модулей.
В октябре 1979 года был сделан предварительный процессор под названием Cpre, который добавил классы, похожие на Simula классы, в C и в марте 1980 года этот предварительный процессор был доработан до такой степени, что он поддерживал один реальный проект и несколько экспериментов. Несмотря на то, что поддержка параллелизма и симуляций в стиле Simula была основной целью C, язык не содержал примитивов для выражения параллелизма. У него была комбинация наследования иерархии классов и способность определять функции членов класса со специальными значения, распознанные препроцессором. Стили были решающими в этом - на языке должно быть выражено более одного понятия параллелизма. Существует множество приложений, для которых необходима поддержка параллелизма, но нет никакой доминирующей модели для поддержки параллелизма; когда необходимая поддержка должна предоставляться через библиотеку или специальное расширение, чтобы конкретная форма поддержки параллелизма не исключала других форм.
Так язык предоставил общие механизмы для организации программ, а не только для поддержки конкретных областей применения. Позднее выбор между предоставлением поддержки специализированных приложений или механизмов общей абстракции неоднократно возникал. Каждый раз принималось решение об улучшении абстракции механизмы.
Раннее описание C с классами было опубликовано как технический отчет Bell Labs в апреле 1980, а затем в SIGPLAN Notices. В апреле 1982 года а затем более подробный технический отчет Bell Labs. Эти документы послужили хорошим примером, описав только те функции, которые были полностью реализованы и были использованы. C с классами был разработан, чтобы обеспечить лучшую организацию программ. Но улучшенная структура программы не была достигнута за счет расходов на время выполнения по сравнению с C. Цель была в том, чтобы соответствовать C по времени выполнения, компактности кода и данных. Но этого не получалось достигнуть. Это было неприемлемым, и накладные расходы были быстро устранены.
Еще одна серьезная проблема заключалась в том, чтобы избежать ограничений на домен, где C с классами мог быть использован. С ней смогли разобраться и C с классами мог делать тоже самое что и C. Это подразумевало, что в дополнение к сопоставлению C в эффективности, C с классами так же не мог устранить опасные функции C. Альтернативным способом обеспечения безопасности была вставка проверок во время выполнения всех небезопасных операций, но язык не может гарантировать такие проверки будут эффективны.
Успех C с классами был простым следствием реализации его проектной цели: он помогал организовать крупные классы программ, значительно лучше, чем C без потери эффективности во время выполнения и не требуя сильных изменений. Факторами, ограничивающими его успех, были частично ограниченный набор новых возможностей, предлагаемых на C, и частично препроцессорная технология, используемая для реализации C с классами. C с классами был важным шагом в правильном направлении, но шагом небольшим. В результате этого начался разрабатываться расширенный преемник C с классами.
Получившийся язык сначала по-прежнему назывался C с классами, но после ему дали имя C84. Причиной было то, что люди называли C с Классами «новый C» и просто C, а сам C назвали «старый C.». Но название C84 использовалось всего несколько месяцев. Поэтому было выбрано новое имя C++. Оно было коротким, хорошо интерпретируемым и не было лишь другой формой C.
В течение 1982-1984 годов цели для C ++ постепенно становились более амбициозными и более определенными. Разработчики инструментов в Bell Labs начали проявлять интерес к C ++, потому началась разработка совершенно новой реализации, которая станет интерфейсом компилятора C ++, Cfront
Первоначальная реализация Cfront была переносимой и дешевой. Именно в этом я и нуждались пользователи и могли себе позволить. Позже, было бы достаточно возможностей для AT&T и других, чтобы обеспечить лучшие инструменты для более специализированных сред. Инструменты, предназначенные прежде всего для промышленных пользователей, также не обязательно должны быть дешевыми, и, таким образом, они смогут оплачивать поддержку, необходимую для широкомасштабного использования языка.
Интерфейс компилятора Cfront для языка C84 был разработан и реализован между весной 1982 и летом 1983 года. Первый пользователь получил свою копию в июле 1983 года. Cfront был традиционным интерфейсом компилятора, выполняющим полную проверку синтаксиса и семантики языка, создавая внутреннее представление его ввода, анализируя и переставляя это представление, и, наконец, производящий выход, подходящий для некоторого генератора кода. Внутренним представлением был граф с одной таблицей символов для каждой области. Принцип состоит в том, чтобы читать исходный файл по одной глобальной декларации за раз и производить вывод только тогда, когда полная глобальная декларация была полностью проанализирована.
Организация Cfront довольно традиционная, за исключением, использования нескольких таблиц символов вместо одного. Cfront был первоначально написан на C с классами и вскоре переведен на C84, так что самый первый рабочий компилятор C ++ был выполнен на C ++. Даже первая версия Cfront использовала классы сильно, но не имела виртуальных функций, потому что они не были доступны в начале проекта.
Самый необычное (для своего времени) аспект Cfront заключался в том, что он сгенерировал C-код. Cfront сгенерировал C, потому что нужна была предельная переносимость для начальной реализации, и C был самым мобильным ассемблером. Впоследствии стратегия создания компилятора как генератора С стала довольно популярной, поэтому такие языки, как Ada, CLOS, Eiffel, Modula-3 и Smalltalk, были реализованы таким образом.
Компилятор С используется только как генератор кода. Любое сообщение об ошибке из компилятора C отражает ошибку в компиляторе C или Cfront, но не в исходном тексте C ++. Каждая синтаксическая и семантическая ошибка в принципе улавливается Cfront. Он был назван препроцессором, потому что он генерирует C, а для людей из сообщества C, это было доказательство того, что Cfront был простая программа - нечто вроде макропроцессора. Из-за этого люди ошибочно думали, что возможен перевод строки из C ++ на C, что символическая отладка на уровне C ++ невозможна при использовании Cfront, что код, сгенерированный Cfront, должен уступать коду созданный «реальными компиляторами», что C ++ не был «реальным языком» и т. д. Cfront является только интерфейсом компилятора и никогда не может использоваться для реального программирования сам по себе. Ему нужен драйвер для запуска исходного файла через препроцессор C, Cpp, а затем запуск вывода Cpp через Cfront и вывод Cfront через компилятор C.
С введением отдельного имени C ++ и написанием справочной материалов C ++ совместимость с C стала проблемой, имеющей большое значение и спорным вопросом. Кроме того, в конце 1983 года филиал Bell Labs, который разработал и поддерживал UNIX и выпускал компьютеры AT&T 3B, заинтересовался C ++ до такой степени, что они были готовы вкладывать ресурсы в разработку инструментов C ++. Такое развитие было необходимо для эволюции C ++ до языка, на котором корпорация могла бы основывать крупные проекты. Это также подразумевало нужду в управлении развития C ++.
Первым требованием было обеспечение 100% совместимости с C. Идеальность совместимости C вполне очевидна и разумна, но в реальности это не было так просто. АNSI C уже был к тому времени, но все еще были годы до стабильного определения. Естественно, что средний пользователь, который хотел C-совместимость, настаивал на том, что C ++ должен быть совместим с местным диалектом C. Позже, после многих технических проблем и большого недовольства пользователей, вложенные классы классов были повторно введены в C ++ в 1989 году, комитет ANSI C принял немного более слабую версию правил и обозначений C ++ в этой точке и объявил применения, которые не соответствуют устаревшим правилам C ++. Было принято правило C, что глобальные имена по умолчанию доступны из других единиц компиляции. Там просто не было поддержки более строгого правила C ++. C ++, как и C, не имеет эффективного механизма выражения модульности над уровнем класса и файла.