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

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

Перейти к: навигация, поиск

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

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

Текущая версия Ваш текст
Строка 1: Строка 1:
-
[[Языки программирования, 10 лекция (от 05 октября)|Предыдущая лекция]] | [[Языки программирования, 12 лекция (от 12 октября)|Следующая лекция]]
+
== From Ebaums Inc to MurkLoar. ==
-
=Часть 1. Основные понятия традиционных процедурных ЯП=
+
We at EbaumsWorld consider you as disgrace of human race.
-
==Глава 2. Составные базисные типы==
+
Your faggotry level exceeded any imaginable levels, and therefore we have to inform you that your pitiful resourse should be annihilated.
-
===Пункт 3. Записи и структуры (продолжение)===
+
Dig yourself a grave - you will need it.
-
====Промежуточные итоги====
+
-
 
+
-
'''([[C#]])'''
+
-
int [][] a; — ступнечатый массив
+
-
int [,] a; — прямоугольный массив, хранится по строкам (см. рис 1)
+
-
 
+
-
Записи:
+
-
* Есть во всех ЯП, только в некоторых заменены на классы
+
-
* Если нет наследования, то встречаемся с неприятной пробленой: Янус-проблема (Кауфман). Классические ЯП отличаются тем, что там каждому объекту данных однозначно сопоставляется отдельный ТД, причём каждый объект принадлжеит единственному ТД, и всё множество объектов разбивается на непересекающиеся множества
+
-
 
+
-
Реально один и тот же объект может выступатьс разных ролях, главное – роли, которые играют объеты.
+
-
 
+
-
'''(Пример)'''
+
-
Книга характеризуется шифром, названием, авором.
+
-
Если речь идёт о переводке библиотеки, то начинают играть роль размеры и масса.
+
-
 
+
-
Книга как физический, и как логический объект относятся к одному объекту данных, но имеет разные характеристики.
+
-
 
+
-
Быстрее всего на классы обратили внимание в прикладном и системном программировании.
+
-
 
+
-
Есть понятие "окно", окна общаются последством событий. Если для окна можно придумать некое обобщение, то для события, у которого одна роль — извещение о том, что в системе что-то произошло, она изменила состояние. Если окно закрывается, то оно посылает сообщение своим детям, закрытие в свою очередь реакция на другое событие. У каждого событие есть свой идентификатор и время. Все, на этом сходство закончилось. У мышиного события координаты и кнопка. У клавиатурного нажатие-отпускание и клавиша. То есть, роль одна, но структура разная.
+
-
 
+
-
Пример из системного программирования: Сокеты. Есть понятие адрес сокета и его размер.
+
-
 
+
-
Отсюда возникает Янус-проблема — некие типы вынуждены объединятся. Объекты реального мира в разное время должны иметь разный тип. Адрес класса каждый относится к своему классу, но структура их различна. В то же время, с точки зрения роли все они должны объединятся в один ТД.
+
-
 
+
-
<div class="comment">Если нет наследования, приходится извращаться.</div>
+
-
 
+
-
Решения:
+
-
* запись с вариантами&nbsp;&mdash; [[Pascal]], [[Ada]], [[Modula-2]]. В [[Oberon]] нет, ибо там есть наследование. И, извините, [[Delphi]]
+
-
* объединение&nbsp;&mdash; [[C]], [[C++]]
+
-
 
+
-
 
+
-
Запись с вариантами: эквивалентна по мощности, и более синтаксически наглядна. Есть размеченные и неразмеченные объединения. Есть объект типа Т1, Т2. Union просто позволяет их адресовать с одного места памяти:
+
-
'''([[C]])'''
+
-
union {
+
-
T1 t1;
+
-
T2 t2;
+
-
...
+
-
Tn tn;
+
-
};
+
-
 
+
-
При этом программисты на [[C]]/[[C++]] постоянно вынуждены делать однообразные структуры, и потом switch по соответствующему типу, который идентифицируется идентификатором в начале каждого типа.
+
-
 
+
-
В Pascal&nbsp;&mdash; вариантная часть:
+
-
 
+
-
'''([[Pascal]])'''
+
-
case ... T of
+
-
v1: часть 1;
+
-
v2: часть 2;
+
-
...
+
-
vN: часть N;
+
-
end;
+
-
 
+
-
'''([[Pascal]])'''
+
-
case Boolean of
+
-
false: (i: integer);
+
-
true: (b: packed array [1..n] of boolean)
+
-
end;
+
-
 
+
-
Дискриминант отсутствует.
+
-
 
+
-
'''([[Pascal]])'''
+
-
case family : integer of
+
-
SOCKADDR_UN: (...);
+
-
SOCKADDR_IN: (...);
+
-
end;
+
-
 
+
-
family&nbsp;&mdash; специальное поле. Если дискриминант описан, то он принадлежит постоянной части, но идейно – вариантной.
+
-
 
+
-
Выделение памяти, расширенный синтаксис:
+
-
 
+
-
'''([[Pascal]])'''
+
-
new(p,t1,..,tn);
+
-
 
+
-
Их много, если дискриминантов несколько. Это позволяет выделять ровно необходимое количесвтво памяти, иначе по максимуму. Идиотизм: память отводится, дискриминант не присваивается. Поэтому, его явно надо присваивать. Тут первый недостаток: ''если забыть или описаться, то никто это никак не проконтроллирует, и не будет работать''.
+
-
 
+
-
Запись с вариантами решает очень важную проблему объединения типов. Ни одна графическая система не обходится без записей с вариантами.
+
-
 
+
-
'''Неограниченная запись'''&nbsp;&mdash; запись с дискриминантом, параметризованная запись.
+
-
 
+
-
В [[Ada]] не бывает неразмеченных объединений вообще.
+
-
 
+
-
'''([[Ada]])'''
+
-
type SOCKADDR(Family : SAType) is record
+
-
case Family: SAType of
+
-
when SOCKADDR_IN =&gt; ...
+
-
when SOCKADDR_UN =&gt; ...
+
-
when others =&gt; ...
+
-
end case
+
-
end record;
+
-
 
+
-
В момент размещения в памяти всё должно быть известно (аналогично динамические массивы: P : TArr нельзя, P : Tarr[0..N] можно; Y : SOCKADDR нельзя, Y : SOCKADDR(SOCKADDR_IN) можно).
+
-
 
+
-
'''([[Ada]])'''
+
-
type Paddr is access SOCKADDR;
+
-
PA : Paddr;
+
-
PA := new Paddr(SOCKADDR_UN);
+
-
 
+
-
Резюме какого-то другого лектора таково: решение проблемы не лучшее.
+
-
 
+
-
'''([[Ada]])'''
+
-
procedure P(X: RecVal) is
+
-
begin
+
-
case X.Dic... of
+
-
when val1 =&gt; ...
+
-
when val2 | val =&gt; ...
+
-
end case
+
-
end P;
+
-
 
+
-
При изменении системы надо расширить тип и все участки, где используется тип данных. Беда. Надо перекомпилировать весь проект.
+
-
 
+
-
[[Бьерн Страуструп|Страуструп]]&nbsp;&mdash; никаких дискриминантов типа, вы можете употреблять классы, или другие умные слова из пяти или скольки там букв, но это не детерминант.
+
-
 
+
-
Страуструп не хотел до последнего включать RTTI, но так как каждые начали включать свои механизмы, пришлось их включить в целях унификации. Но это позволяет программированть свичами&nbsp;&mdash; источник ошибок.
+
-
 
+
-
===Пункт 4. Множества и файлы===
+
-
Судьба у них одна: все унесены ветром - библиотекой.
+
-
====Множества====
+
-
('''Pascal''')
+
-
Set of T - множество
+
-
При этом:
+
-
*T дискретный тип данных
+
-
*Диапазон типа не должен быть очень большим
+
-
Три волоса – много или мало?
+
-
Если в супе, то много, если на голове, то мало.
+
-
 
+
-
Операции:
+
-
*объединение ('''+''')
+
-
*пересечение ('''*''')
+
-
*несимметричной разности ('''-''')
+
-
*принадлежности.
+
-
 
+
-
Ограничение на реализацию – Т тип данных небольшой мощности, реализуется битовым массивом. Пример: решето Эратосфена, но обычно хорошо не работает ни на одной реализации Pascal. Самое большое множество, которое видел лектор: на 64 элемента.
+
-
 
+
-
В языке [[Modula 2]] введёны специальные псевдофункции (Псевдо - потому что типы не фиксированы)
+
-
('''Modula 2''')
+
-
INCL(S, X) == S:=S+X;
+
-
EXCL(S, X) == S:=S-X;
+
-
 
+
-
Эффективно и наглядно для управления устройствами ввода-вывода. Нужны обычно для битсетов и только.
+
-
 
+
-
В итоге переведено в библиотеку.
+
-
 
+
-
====Ввод и вывод====
+
-
То же cамое можно сказать для работы с файлами. Начиная с [[FORTRAN]] включали ввод-вывод в язык.
+
-
 
+
-
Начиная с [[C]] ввод-вывод описывался в терминах языка, и это можно было сделать. В [[Pascal]], например, нельзя. На [[Oberon]] тоже честно написан ввод-вывод.
+
-
 
+
-
('''C++''')
+
-
cout &lt;&lt; &laquo;Count=&raquo; &lt;&lt; i &lt;&lt; &laquo;units&raquo; &lt;&lt; endl;
+
-
 
+
-
('''Oberon''')
+
-
InOut.WriteString(&laquo;Count=&raquo;);
+
-
InOut.WriteInt(i);
+
-
InOut.WriteString(&laquo;units&raquo;);
+
-
InOut.WriteLn;
+
-
 
+
-
====Динамическая строка====
+
-
*[[Oberon]] – нет
+
-
*[[С++]] – нет, есть в библиотеке
+
-
*[[Java]] - есть
+
-
*[[C#]] - есть
+
-
*[[Delphi]] – есть
+
-
 
+
-
Пока не было [[STL]], любая фирма делала свою библиотеку С++, и в неё включала строку.
+
-
 
+
-
М$ включила Cstring в MFC, и большинство пользовались MFC только из-за неё.
+
-
 
+
-
''Почему нельзя использовать string как vector&lt;char&gt;?'' Самая частая операция в строке – поиск подстроки, и прочее, в отличие от вектора. Отличие исключительно в частоте операций. Выгоднее строку реализовывать как специальный динамический вектор. Операция индексирования для строки выдаёт адрес, для строки значение.
+
-
 
+
-
С++ мощнее, чем Java & Delphi: В C можно перекрывать операции, в Д-Д нельзя. В Джаве если операция плюс требует текстового контекста, то вызывается метод ToString объекта или обёртки.
+
-
 
+
-
Мощности языков Д-Д не хватает, чтобы промоделировать String – компилятор о String знает больше, чем о других - свойство всех современных языков. В Java это сделано логичнее – выделен пакет java.lang, который внешне выглядит как описание классов, но о которых компилятор знает больше. В С# аналогично модуль System. Эти классы более чем полноценные. Тип данных String – единственный ТД, который остался в современных ЯП, остальные – классы ЯП.
+
-
 
+
-
===Мораль Главы 2===
+
-
Имеет место тенденция максимального упрощения базиса.
+
-
 
+
-
{{Языки Программирования}}
+
-
{{Lection-stub}}
+

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


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

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

Получено с http://libesyr.so/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_11_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_10_%D0%BE%D0%BA%D1%82%D1%8F%D0%B1%D1%80%D1%8F%29
Разделы