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

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

 

==== goto ====

<p>J C# D отличает от C++ референциальная модель объектов. Объект нужно создать. В C++ есть конструкторы и деструкторы, и когда объект перестаёт существовать в памяти, автоматически вызывается деструктор. В С++ захват ресурсов – инициализация. Если нам нужен ресурс, мы обрамляем его в класс Res, в конструкторе которого желается захват ресурса, в деструкторе – освобождение. И при любом выходе из стека будут вызываться деструкторы объектов, влекущие за собой освобождение ресурсов. В JDC# есть конструкции, которые позволяют эмулировать эту стратегию.</p>

<p>Мы размещаем курсор в стеке, вызывааем долгую операцию. В чём проблема: даже если не работала такая семантика, </p>

<p>В Модуле-3 главное понятие – Remote Procedure Call (RPC).</p>

=== Пункт 3. Составной оператор или блок. ===

<p>Чем отличается сост оператор от блока. В Алголе не отличается, в Паскале – да.</p>

<p>Как только возникает разделение объявлений и операторов, при этом понятие составного оператора необязательно. Может быть в языке отдельно блок и отдельно оператор. Такое понятие нужно чисто синтаксически в языках, где отсутствует явный терминатор.</p>

<p>Ада, М-2, Оберон – понятие сост оператора отсутствует, так как там должно быть ключевое слово для начала блока.</p>

<p>В программировании 70х годов считалось, что нужно опережающее описание всех переменных. Причём в Аде считалось, что нужно сначала тому, кто читает, знать обо всех объектах, а потом читать, что делается. Смешение считалось дурным тоном.</p>

<p>В Паскале сверху блока может быть либо заголовок процедуры, либо заголовок главной программы. </p>

<p>В современных ЯП блок эквивалентен составному оператору. (Си++, Java, Си#). В современных языках беспорядочное объявление операторов является господствующим. </p>

=== Пункт 4. Специализированные операторы. ===

<p>Для языка Ада есть два оператора: select, accept. Относятся к области взаимодействия параллельных процессов, и их аналогов в других ЯП нет или почти нет. Каждый ЯП может ввести некоторые специализированные операторы. И при изучении на них надо обращать внимание.</p>

== Глава 4. Процедурные абстракции. ==

<p>Ка с тз операторного базиса, так и с тз типового базиса ЯП, несильно отличаются друг от друго.</p>

<p>Набор ТД сильно сократился по сравнению со старыми ЯП, набор конструкции тоже. Базисные встроенные объекты с объектами реального мира имеют мало общего, кирпичики, из которого строят модели, очень маленькие и универсальные. Для этого предлагаются некие повторно используемые библиотеки. Например, есть STL, а есть открытые библиотеки типа boost. &laquo;то уже более мощные ЯП. В совр ЯП делается брлее мощный упор на средства развития.</p>

<p>Что нужно в языке: язык ассемблера – трудно развиваемый язык, ничего с т.зр. развития нет.</p>

<p>А то, что сделали на ASMе и джовиале, очень трудно передать.</p>

<p>Можно объектно программировать на ASMе.</p>

<p>На Фортране 66 года можно было создавать достаточно сложные системы, например компилятор компиляторов. Пользовались двумя вещами – подпрограмма (возникла в самом первом варианте), и блок данных (возник тогда же – ужасно неприятно синтаксическая конструкция, но он позволял</p>

<p>BLOCK DATE имя</p>

<p>Блок данных – изначально средство экономии памяти. Потом выяснилось, что необходим набор глобальных данных для взаимодействия разных модулей.</p>

=== Пункт 1. Процедуры и сопрограммы. ===

<p>Понятие процедуры соотв понятию структурного программирования. Это чёрный ящик, у которого один вход и один выход, а там внутри уже делается что угодно. Но в первых ЯП очевидно было, что процедура – нечто, которое может иметь и несколько входов, и несколько выходов. Фортран 77 объединял в себе особенности, которые появились в новых компиляторах. Там кроме SUBROUTINE был ENTRY – это были альтернативные входы, причём альтернативные входы могли иметь альтернативные наборы параметров.</p>

<p>Было ещё одно понятие, которое было изгнано из совр ЯП: сопрограмма.</p>

<p>Процедура: процедура p подразумевает всегда вызов её из надпрограммы, вызывающей, главной. В каждый конкретный момент времени вызов программа становится главной. Причём тут асимметрия: p – точка входа (в ассемблере процедура не отличается от метки. Любимая задача лектора: если не call, как его промоделироваать, но тут ещё надо в стек загрузить адрес возврата. В 360 не было call, зато был такой косвенный оператор перехода). Всегда при вызове процедуры всегда с первого оператора, а возвращение туда, откуда вызвали, куда скажут. Чёткая асимметрия.</p>

<p>Как обобщить подобную антисимметрию и сделать её симметричной: для этого назовём это сопрограммой (coroutine) – взаимодействующие программы.</p>

<p>Есть call p2 – управление идёт в точку входа p2, потом делаем call p1, возвращаем туда, откуда вызвали, потом опять делаем call p2, и возвращаем управление туда, откуда ушли. Тут это вместо call называется resume. При resume начинается выполнение соответствующей сопрограммы с точки, где её покинуло.</p>

<p>Книга структурное программирование – три статьи – первая Дейкстры про структурное программиорваиние, вторая Ховарда про типы данных. Третья Уве Дау (один из автор Симулы 67 – основной источник идей для Страуструпа при создании Си с классами), в которой он обсуждал понятие сопрограммы, реализацию в Симуле, возможности применения, насколько оно красивее.</p>

<p>Явный пример: нужно слить два файла. Не очень приятная задача, нужно гонять циклы то там, то там. Кроме того, возникают лишние циклы, когда один из файлов закончился. А при сопрограммах обе сопрограммы читают из своего файла в результирующий, вопрос в том, когда передавать управление, и тут всего один цикл. Сигнализация конца файла легко устанавливается и она решается за один цикл. Структура решения более простая, чем при классическом решении. Структура сопрограмм похоже на процессы. Это суть квазипараллельные процессы, и с точки параллельных процессов resume соответствует синхронизации. Для многих задач параллельные процессы естественнее, чем последовательные. Сопрограммы были впервые применены для реализации с языка Cobol. С точки зрения компиляции на что похожа сопрограмма – есть сопрограммы для лексического, синтаксического анализа, генерации кода. Тогда, когда синтаксический анализатору нужна лексема, он вызывает лексический анализатор, и он её отдаёт. Синтаксический анализатор из потока читает лексемы и отдаёт их генератору кода. Компилятор есть сеть взаимодействующих сопрограмм, и эта концепция всем понравилась. Она была внедрена в Симулу 67 и Модулу-2. Для поддержки сопрограмм были:</p>

<p>Очень похоже на запуск нового потока. Там мы указываем процедуру без параметров (в виндах можно указывать параметр – код возврата). </p>

<p>Была ещё процедура IOTRANSFER – вызов процедуры, когда приходило прерывание, там ещё было N – номер прерывание. Это позволяло писать драйверы. Это понятие сопрограммы могло быт полезным, например, при обработке нажатий клавиш.</p>

<p>Основываясь на понятии сопрограммы, можно реализовать передачу сигналов. То есть понятие сигналов – квазипараллельного программирования, на основе сопрограмм.</p>

<p>Один из главных недостатков сопргр=ограмм – сложность синхронизации оп данным. У каждой сопрограммы свой стек, где хранятся локальные данные. Сопрограммы могут взаимодействовать только через глобальные переменные. Они не могут экспортировать данные наружу.</p>

<p>Лектору кажется, что отсутствие понятия сопрограмм связано с наличием других средств квазипараллеьного программирования реализуемых ср-вами стандартной библиотеки или ОС.</p>

<p>Явным преимущественным Ада – механизм синхронизации процессов (механизм рандеву). Единственная новая концепция. Accept – принимал некоторую точку входа от параллельного процесса. Механизм рандеву всем хорош, но если программировать параллельные процессы на ОС, где пар процессы уже есть, то получалось менее эффективно. И он был полезен, где пар процессов вообще не было. Но там есть ограничение по ресурсам, и там механизм рандеву – стрельба из пушки по воробьям.</p>

<p>В Java есть встроенные средства программирования потоков, кроме того, там есть JNI, чему сопротивлялась Sun, но чего так хотела MS, - вызов нативного кода. Это напрямую противоречит WORA. Но получается так, что реализация встроенного механизма, оказывается менее эфективной, чем использование средств ОС. </p>

<p>Встроенный механизм сопрограмм слишком низкоуровневый, и его нельзя реализовать достаточно универсально на разных архитектурах (ОС). Современные программисты потеряли вкус к параллельному программированию. Их не нужно применять для эффективности, их нужно применять для соотв структуре алгоритма.</p>

=== Пункт 2. Подпрограммы. Передача параметров.===

<p>Разные ЯП отличаются с т.зр. реализации отличаются механизмом передачи параметров.</p>

<p>Первый класс – in-параметры – передаются только их значения</p>

<p>Главный недостаток этих способов – копирование, если параметры большие. Понадобились ещё два способа:</p>