Редактирование: Языки программирования, 05 лекция (от 19 сентября)

Материал из eSyr's wiki.

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.

[[Языки программирования, 04 лекция (от 14 сентября)|Предыдущая лекция]] | [[Языки программирования, 06 лекция (от 21 сентября)|Следующая лекция]]

==Связывание==
Статическое связывание&nbsp;— во время компиляции
Динамическое связывание&nbsp;— в момент выполнения

*Данный код на [[С++]]:
 ('''C++''')
 Х х;
 Х.F();
*Транслируется в:
 ('''Asm''')
 CALL _F
Когда произойдёт  связывание? Кто и в какой момент решает?  Правильный из вызова дать нельзя. Для  ответа надо посмотреть на объявление  Х, и посмотреть, виртуальная функция  или нет. Но это может быть недостаточно,  так как Х может быть унаследован от ХХ,  где функция объявлена виртуальной. Для невиртуальных  методов можно по тексту программы можно  определить, какая функция вызывается,  для виртуальных&nbsp;— в общем случае  нет.

==Виртуальная машина==
Виртуальная машина  языка&nbsp;— некая машина, у  которой язык программирования является  машинным языком. Это понятие возникло  в 60-е годы на базе языка [[Algol|Algol 60]], так как  понятие ВМ позволило разделить окружение  языка и сам язык. До Алгол 60 окружение  включалось в язык, например, у Паскаля  стандартные функции (ввод-вывод) есть  часть языка.

Понятие виртуальной машины оказалось не чисто теоретическим понятием. Сейчас понятие ВМ является часто употребляемым и не столь ясным. Идея реализовать в железе ВМ было довольно частой, особенно в 60–70 годы. 
*SYMBOL (Европа и Америка) для, которой языком был '''Алгол 60''' (не являлась чистой, так как некоторые конструкции языка не были реализованы).
*Burroughs работал на расширенном варианте '''Алгол 60''' со стеком и был чистой ВМ
*в СССР для машин Мир–1, 2, 3 единственным языком был '''[[Аналитик]]'''&nbsp;— русифицированный и расширенный вариант Алгол 60, например в Аналитике были опреации для символьного дифференцирования и интегрирования. Но в последствии развитие собственных машин было убито и СССР перешло на копирование чужих платформ.
*В 70-е годы получили распространение '''[[LISP]]-ВМ''' (LISP-machines). Аппаратная реализация была нужна для увеличения быстродействия.
Сейчас с точки зрения количества различных архитектур сейчас их не очень много. И аппаратная реализация выглядит анахронизмом, так как реализация эта дорогая и, что еще хуже - не гибкая, так как языки сложны и отсутствует универсальный язык. Кроме того, в языке имеются недостатки, эти недостатки распространяются на архитектуру. Сейчас же языки ориентируются на архитектуру и базис очень и очень примитивен.

===Понятие ВМ в том виде, в котором оно сформировалось===
Стандартным вариантом языка [[Smalltalk]] есть реализация в виде байт-кода. Была попытка аппаратной реализации этой ВМ в виде Катаны (так и не была реализована), но была программная реализация. Понятие ВМ&nbsp;— JVM&nbsp;— [[Java]] Virtual Machine.Sun стандартизовала язык Java, байт-код и набор системных вызовов = Java RunTime. Любой интерпретатор - и есть JVM. Понятие ВМ оказалось достаточно мощным и гибким. Понятно, за счёт чего обеспечивается гибкость. За счёт того, что мы не зависим от реализации. Программы, удовлетворяющие стандарту Pure Java, действительно переносимы.

Чем мы платим? '''Производительностью'''. Например, Lotus Notes, написанная на Java, сильно тормозит. Как только речь идёт о нетривиальных приложениях, сказываются проблемы с производительностью. Спор о эффективности-неэффективности ведётся с [[1950-е|50-х]] годов.
 Каждые 10 лет говорят, что через 10 лет компьютеры будут так быстры, что ничего уже не будет тормозить.
Действиетльно, сейчас эффективности уделяется меньшее внимание, о чём говорит распространение скриптовых языков&nbsp;— [[PHP]], [[Perl]], [[JSP]], [[ASP]], они используются на стороне сервера. Но они остаются достаточно специализированными, они занимаются обработкой и генерацией текста, и с точки зрения программирования это достаточно узкая область, а Java претендовала на роль универсального языка, и роль эффективности тут больше.

.NET Framework ещё одна попытка, где стандартизируется только окружение, а не байт-код. ЯП.NET&nbsp;— MIL&nbsp;— JIT компиляция. Это несколько более эффективно. То есть стандартизован некий виртуальный язык. Одно время говорили, что вместо WinAPI будут использовать защищённые вызовы .NET, но это нескоро, так как как только начинаешь писать что-то хитрое, сразу надо вспоминать, как вызывать WinAPI.

=Часть 1. Основные понятия традиционных процедурных ЯП=
Будем рассматривать не Алгол и Фортран, а современные ООП языки, точнее ту часть, где они наследуют традиционную парадигму
#Базис
#*скалярный
#*структурный
#Средства развития
#Средства защиты

==Глава 1. Скалярный базис.==
===Пункт 1. Классификация простых типов данных===
Простые типы данных (они же примитивные)&nbsp;— не имеют внутр структуры. 
*Арифметические типы
**Целые
**Вещественные
***С плавающей точкой
***С фиксированной точкой&nbsp;— не во всех языка поддерживается это разделение
*Логический тип
*Символьные типы
Целые, символьные и логические ТД сводятся к целым.

Типы, основанные на  других типах:
*Ссылочные типы / Указатели
*Порядковые типы
**Перечисление
**Диапазон&nbsp;—   	производный тип данных, опирающийся на другой тип данных&nbsp;—  перечислимый
*Процедурные (функциональные) типы данных&nbsp;—  не есть указатель, но его разновидность&nbsp;—  	 в [[Modula|Modula-2]], [[Oberon]], [[Ada|Ada 95]].

Любой ЯП обладает  подобным набором ТД. Традиционно базысным типом является целый тип. Инновационный подход - использование строк как базисного типа.

===Пункт 2. Целые типы и проблема представления  беззнаковых чисел===
Две проблемы, возникающие  при реализации целых чисел: Представление беззнаковых чисел и длина

Решения проблемы знаковых-беззнаковых типов:
<ol>
 <li>
 [[Pascal]]&nbsp;— 	 два отдельных типа
 </li>
 <li>
 C&nbsp;— две разновидности 	типа
 </li>
 <li>
 Java&nbsp;— только 	знаковый
 </li>
</ol>

в [[C#]]&nbsp;— все типы парами: short&nbsp;— ushort; int&nbsp;— uint; long&nbsp;— ulong. По традиции byte беззнаковый, посему sbyte&nbsp;— byte. Длина зафиксирована: byte – 1, short – 2, int – 4, long – 8 байт.

Какая проблема связана с беззнаковым типом&nbsp;— проблема преобразований из и в знаковый тип.
*Классический пример (На одной архитектуре он зацикливается, на другой работает нормально):
 ('''C''') 
 char c;
 while ((c=getchar())!=EOF) {}
Проблема в том, что EOF&nbsp;= –1. И все функции стандартной библ возвращают знаковый тип&nbsp;— int. В одних архитектурах char знаковый, в других&nbsp;— беззнаковый. Тогда получаем такую цепочку преобразований:
 0xFFFF =&gt; 0xFF =&gt; 0x00FF.
Для правильной реализации надо писать int c.

В стандартном Паскале не было беззнаковых типов.
В [[Modula|Modula-2]] было два типа INTEGER и CARDINAL, которые неявно друг к другу не преобразовывались.
Программист-профессионал должен включать макс уровень предупреждений и добиваться, чтобы у него предупреждений не было.
Была мода в [[1980-е|80-е годы]] делать знаковый и беззнаковый типы несовместимыми, так как явное преобразование заставляет задумываться над ошибками. Страуструп в первом варианте Си с классами запретил преобразование между знаковыми и беззнаковыми типами. Ни одна из существ программ на языке C не прошла тест на компиляцию в первом варианте C++. Но эти программы работают, правильно работают. Объяснение состоит в том, что профессионалы представляют проблемы, с этим связанные, и эти проблемы решают. В результате неявные преобразования были разрешены (так как главным критерием при проектировании С++ являлась совместимость со стандартными библиотеками), но при опасных выдаётся предупреждения. Дабы не ограничивать возможности программиста, [[Страуструп]] в результате сдался.

Другим решением была в [[Java]], самое простое решение&nbsp;— запретили беззнаковые типы данных. А зачем вообще нужны беззнаковые типы? Чуть больше диапазон значений в одну сторону, что было важно раньше, когда ''машины были большие, а байты маленькие''. И беззнаковые типы тогда были нужны.

В Pascal не было беззнаковых типов&nbsp;— В Modula-2 были два несовместимых типа&nbsp;— В Обероне один беззнаковый тип байт и остальные только знаковые.
Modula создавалась для 16 битных архитектур, и это было важно, а Oberon для 32, где неважно, 2 миллиарда или 4.

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

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Описание изменений:

Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.us/wiki/%D0%AF%D0%B7%D1%8B%D0%BA%D0%B8_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%2C_05_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_19_%D1%81%D0%B5%D0%BD%D1%82%D1%8F%D0%B1%D1%80%D1%8F%29

@@ Строка 24: / Строка 24: @@
 Понятие виртуальной  машины оказалось не чисто теоретическим  понятием. Сейчас понятие ВМ является  часто употребляемым и не столь ясным.  Идея реализовать в железе ВМ было довольно частой, особенно в 60–70 годы.
-*SYMBOL (Европа и  Америка), для которой языком был '''Алгол 60''' (не являлась чистой, так как некоторые конструкции языка не были реализованы).
+*SYMBOL (Европа и  Америка) для, которой языком был '''Алгол 60''' (не являлась чистой, так как некоторые конструкции языка не были реализованы).
 *Burroughs работал на расширенном варианте '''Алгол 60''' со стеком и был чистой ВМ
-*в СССР  для машин Мир–1, 2, 3 единственным языком  был '''[[Аналитик]]'''&nbsp;—  русифицированный и  расширенный вариант Алгол 60, например  в Аналитике были операции для символьного  дифференцирования и интегрирования. Но впоследствии развитие собственных машин было убито и СССР перешло на копирование чужих платформ.</p>
+*в СССР  для машин Мир–1, 2, 3 единственным языком  был '''[[Аналитик]]'''&nbsp;—  русифицированный и  расширенный вариант Алгол 60, например  в Аналитике были опреации для символьного  дифференцирования и интегрирования. Но в последствии развитие собственных машин было убито и СССР перешло на копирование чужих платформ.</p>
 *В 70-е годы получили  распространение '''[[LISP]]-ВМ''' (LISP-<span lang="en-US" xml:lang="en-US">machines</span>).  Аппаратная реализация была нужна для  увеличения быстродействия.
-Сейчас количество различных архитектур невелико. И аппаратная реализация выглядит анахронизмом, так как реализация  эта дорогая и, что ещё хуже, негибкая, так как языки сложны и  отсутствует универсальный язык. Кроме  того, в языке имеются недостатки, эти  недостатки распространяются на  архитектуру. Сейчас же языки ориентируются  на архитектуру и базис очень и очень  примитивен.
+Сейчас с точки зрения  количества различных архитектур сейчас их не очень много. И аппаратная реализация выглядит анахронизмом, так как реализация  эта дорогая и, что еще хуже - не гибкая, так как языки сложны и  отсутствует универсальный язык. Кроме  того, в языке имеются недостатки, эти  недостатки распространяются на  архитектуру. Сейчас же языки ориентируются  на архитектуру и базис очень и очень  примитивен.
 ===Понятие ВМ в том виде, в  котором оно сформировалось===
-Реализация в виде транслятора в байт-код и оного интерпретатора стандартна для языка <span lang="en-US" xml:lang="en-US">Smalltalk</span>. Попытка аппаратной  реализации этой ВМ ("Катана") провалилась.
+Стандартным вариантом  языка <span lang="en-US" xml:lang="en-US">[[Smalltalk]]</span> есть реализация  в виде байт-кода. Была попытка аппаратной  реализации этой ВМ в виде Катаны (так и  не была реализована), но была программная  реализация. Понятие ВМ&nbsp;—  JVM&nbsp;—   [[Java]] <span lang="en-US" xml:lang="en-US">Virtual</span> <span lang="en-US" xml:lang="en-US">Machine.</span>Sun стандартизовала язык  Java, байт-код и набор системных вызовов  = Java RunTime. Любой интерпретатор - и есть  JVM. Понятие ВМ оказалось достаточно  мощным и гибким. Понятно, за счёт чего  обеспечивается гибкость. За счёт того,  что мы не зависим от реализации. Программы,  удовлетворяющие стандарту <span lang="en-US" xml:lang="en-US">Pure</span> Java, действительно переносимы.
+Чем мы платим?  '''Производительностью'''. Например, <span lang="en-US" xml:lang="en-US">Lotus</span> <span lang="en-US" xml:lang="en-US">Notes</span>, написанная на Java,  сильно тормозит. Как только речь идёт  о нетривиальных приложениях, сказываются  проблемы с производительностью. Спор  о эффективности-неэффективности ведётся  с [[1950-е|50-х]] годов.
+ Каждые 10 лет говорят, что через 10 лет компьютеры будут так быстры, что ничего уже не будет тормозить.
+Действиетльно, сейчас  эффективности уделяется меньшее  внимание, о чём говорит распространение  скриптовых языков&nbsp;—  [[PHP]], <span lang="en-US" xml:lang="en-US">[[Perl]]</span>,  [[JSP]], [[ASP]], они используются на стороне  сервера. Но они остаются достаточно  специализированными, они занимаются  обработкой и генерацией текста, и с  точки зрения программирования это  достаточно узкая область, а Java претендовала  на роль универсального языка, и роль  эффективности тут больше.
+.NET <span lang="en-US" xml:lang="en-US">Framework</span> ещё одна попытка, где стандартизируется  только окружение, а не байт-код. ЯП.NET&nbsp;—   MIL&nbsp;—  JIT компиляция. Это несколько  более эффективно. То есть стандартизован  некий виртуальный язык. Одно время говорили,  что вместо WinAPI будут использовать  защищённые вызовы .NET, но это нескоро,  так как как только начинаешь писать  что-то хитрое, сразу надо вспоминать,  как вызывать WinAPI.
-Популярна ВМ для языка Java&nbsp;—  JVM (Java <span lang="en-US" xml:lang="en-US">Virtual</span> <span lang="en-US" xml:lang="en-US">Machine).</span> Sun стандартизовала язык  Java, байт-код и набор системных вызовов. Любой интерпретатор байт-кода (например, JRT &mdash; Java RunTime) есть конкретное воплощение JVM.
-Понятие ВМ оказалось достаточно  мощным и гибким. Понятно, за счёт чего  обеспечивается гибкость. За счёт того,  что мы не зависим от реализации. Например, программы,  удовлетворяющие стандарту "<span lang="en-US" xml:lang="en-US">Pure</span> Java", действительно переносимы.
-Чем мы платим?  '''Производительностью'''. Например, <span lang="en-US" xml:lang="en-US">Lotus</span> <span lang="en-US" xml:lang="en-US">Notes</span>, написанная на Java,  сильно тормозит. Как только речь идёт  о нетривиальных приложениях, сказываются  проблемы с производительностью. Спор  об эффективности-неэффективности ведётся  с [[1950-е|50-х]] годов.
- Каждые 10 лет говорят, что через 10 лет компьютеры будут так быстры, что ничего уже не будет тормозить.
-Действительно, сейчас  эффективности уделяется меньшее  внимание, о чём говорит распространение  скриптовых языков&nbsp;—  [[PHP]], <span lang="en-US" xml:lang="en-US">[[Perl]]</span>,  [[JSP]], [[ASP]], [[Python]], [[Ruby]]. Они используются на стороне  сервера, но остаются достаточно  специализированными, занимаются  обработкой и генерацией текста, и, с  точки зрения программирования, это  достаточно узкая область, а Java претендовала  на роль универсального языка, и роль  эффективности тут больше.
-.NET <span lang="en-US" xml:lang="en-US">Framework</span> &mdash; ещё одна попытка, где стандартизируется  только окружение, а не байт-код. ЯП .NET&nbsp;—   MIL&nbsp;—  компилируется just-in-time (JIT). Это несколько  более эффективно. То есть, стандартизован  некий виртуальный язык. Одно время говорили,  что вместо WinAPI будут использовать  защищённые вызовы .NET, но это нескоро,  так как как только начинаешь писать  что-то хитрое, сразу надо вспоминать,  как вызывать WinAPI.
 =Часть 1. Основные понятия  традиционных процедурных ЯП=

Редактирование: Языки программирования, 05 лекция (от 19 сентября)

Материал из eSyr's wiki.

Просмотры

Личные инструменты

Навигация

инструменты

Разделы

Спецкурсы

9 семестр

7 семестр

5 семестр

3 семестр

Поиск

Инструменты