Мои впечатления о лекции Н. Вирта в ННГУ 26.09.2005 - Философия программирования

Дарней wrote:

> C>ISO-IEC-14882(2003): описание языка заканчивается на 296 странице,
> Такой же в точности версии у меня нет, так что сравнить не могу.
> Однако, никакой четкой границы между описанием собственно языка и
> библиотек там не прослеживается.

Граница там абсолютно четкая:

15. Exception handling
16. Preprocessor directives
17. Library introduction.

Ну можно в спеку самого языка еще добавить 20 страниц "Language support
library". Все равно до C# не дотягивает.

> C>(C# Language Working Draft 2.7, June 2004 (PDF)): описан только язык,
> C>без послесловий всего 454 страницы.
> Только язык? А как же соглашения об именовании, например? Описание
> грамматики? Описание генератора документации?

Только язык. Соглашения о наименовании и грамматику я включил в оба
стандарта языка. Описание генератора документации в C# я специально
пропустил.

> да и вообще спор не имеет особого смысла. Сложность грамматики и
> сложность реализации языка — вещи совершенно перпендикулярные.
> Достаточно вспомнить про тот же самый экспорт шаблонов.

Экспорт шаблонов — это не сверхсуперсложная фича, просто для ее
реализации приходилось менять само ядро компилятора.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

Трурль wrote:

> I went to a Pascal conference in Southampton in 1977 and Brinch-Hansen
> described Concurrent
> Pascal. When asked what he thought of Modula (that Wirth just had
> brought out), he replied that
> you might do something clever but then "Claus" would come with the
> worked-through elegant version of it!

К чему бы это? Никто вроде бы не спорит, что для своего времени (70-80е
годы) Паскаль и его последователи были одними из лучших языков. Только
вот времени с 77 года уже скоро 30 лет будет.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

Здравствуйте, Cyberax, Вы писали:

>> Даже распоследний ассемблер. Был бы только компилятор под нужную
>> платформу

C>Только вот программа на ассемблере не будет выполняться на другой
C>архитектуре. А вот программа на С — будет.

Будет-будет, главное иметь правильный компилятор

Эмулятор нужной архитекутры, написанный на одном из "кроссплатформенных языков"
+ компилятор с ассеблера в код на вышеупоянутом языке взаимодействующий с эмулятором +
уже "настоящий" компилятор в машинный код с "кроссплатформенного языка"

^^^ продолжение анекдота.

Здравствуйте, Cyberax, Вы писали:

C>Граница там абсолютно четкая:
C>

C>15. Exception handling
C>16. Preprocessor directives
C>17. Library introduction.

C>Ну можно в спеку самого языка еще добавить 20 страниц "Language support
C>library". Все равно до C# не дотягивает.

То есть вот это, например:

18.4 Dynamic memory management 337

уже не является частью описания языка? Лихо ты с ним обошелся

C>Экспорт шаблонов — это не сверхсуперсложная фича, просто для ее
C>реализации приходилось менять само ядро компилятора.

ну да, ввести четвертую стадию обработки кода — прелинкер.
всего навсего

ладно, неважно это всё

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, eao197, Вы писали:

E>Не менее отличный набор, чем:
E>

E>Write once, run everywhere

E>Как выясняется, только набором он и остался.

Ну отчего же, если не путать желаемое с предлагаемым, то вполне себе правильный слова.
Так оно на практике и есть.

Компилируем один раз. Запускаем на какой угодно платформе, где стоит jdk нужной версии + есть порты не pure java библиотек, если таковые использовались (например, swt). Естественно, с точностью до багов реализации %)

Если вам обещали большее... — я точно ничего не могу поделать с этим

E>Ты сам пришел к правильному выводу: язык является кроссплатформенным, если на разных платформах есть компиляторы этого языка. Я бы добавил, что эти компиляторы должны уметь компилировать корректные программы, которые не используют не описанные в стандарте (платформо-зависимые) вещи.

Тут вольно — не вольно задумаешься.

Если есть стандарт "теоретический" и есть компиляторы, которые являются стандартном "практическим", и эти стандарты различаются (причём даже зависят от платформы), то говорить "язык Y@@" мы вообще не имеем права,
т.к. для разных языков используются одно название! Что в свою очередь даёт только повод к путанице и пространство для игры со словами, тем самым лишая смысла большую часть высказываний, поскольку они не могут быть в результате выражены
просто и однозначно

E>А посколько на DEC Alpha вряли есть x86 ассемблер, то x86 ассемблер не является кроссплатформенным.

По-этому поводу я ответил в посте рядом

Здравствуйте, NotGonnaGetUs, Вы писали:

E>>

E>>Write once, run everywhere

E>>Как выясняется, только набором он и остался.

NGG>Ну отчего же, если не путать желаемое с предлагаемым, то вполне себе правильный слова.
NGG>Так оно на практике и есть.

NGG>Компилируем один раз. Запускаем на какой угодно платформе, где стоит jdk нужной версии + есть порты не pure java библиотек, если таковые использовались (например, swt). Естественно, с точностью до багов реализации %)

Так ведь, если программа состоит только из if, switch и return, а из jdk использует только java.lang, то все так и есть. А если взять какую нибудь Java реализацию для SIM-карт (не для телефонов, хотя я слышал, что и у телефонов с поддержкой j2me так же есть проблемы с совместимостью JDK), то окажется, что весь API там свой. Да еще и сама Java урезана так, что даже лишний вызов метода не сделаешь, т.к. под стек всего 256 байт отводится. Вот и получается, что Java-приложение для такой платформы имеет с Java-приложением для другой платформы общего только название Java.

Тоже самое можно сказать и о C/C++. Пока ты пользуешься STL/stdlibc -- твои программы вполне себе переносимы. А взял FindFirst вместо opendir -- все, кроссплатформенность кончилась.

E>>Ты сам пришел к правильному выводу: язык является кроссплатформенным, если на разных платформах есть компиляторы этого языка. Я бы добавил, что эти компиляторы должны уметь компилировать корректные программы, которые не используют не описанные в стандарте (платформо-зависимые) вещи.

NGG>Тут вольно — не вольно задумаешься.

NGG>Если есть стандарт "теоретический" и есть компиляторы, которые являются стандартном "практическим", и эти стандарты различаются (причём даже зависят от платформы), то говорить "язык Y@@" мы вообще не имеем права,

А стандарт C++ по-твоему -- это "теоритический" стандарт?
В такой же ситуации находится и Java, если брать Sun Java и GNU Java Compiler.
Или C# от MS или Mono, или DotGNU.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, Cyberax, Вы писали:

C>>Дарней wrote:

>>> ПК>Объем спецификации C# 2 не меньше, чем объем спецификации C++ даже,
>>> особенно при учете того, что спецификация C++ заметно подробнее.
>>> Откуда дровишки?

C>>Скачай и сравни сам.

Д>Да я вот и сравнил. C# 2.0 — 115 страницы, C++ — 776 страниц. Спека по C++ к тому же далеко не самая свежая. И где ты тут усмотрел, что у C# она "не меньше"?
а кто подскажет откуда можно с++ спецификацию посл. скачать? так сказать почитать на сон грядущий

... << RSDN@Home 1.2.0 alpha rev. 618>>

Здравствуйте, eao197, Вы писали:

E>Так ведь, если программа состоит только из if, switch и return, а из jdk использует только java.lang, то все так и
E>есть. А если взять какую нибудь Java реализацию для SIM-карт (не для телефонов, хотя я слышал, что и у телефонов с
E>поддержкой j2me так же есть проблемы с совместимостью JDK), то окажется, что весь API там свой. Да еще и сама Java
E>урезана так, что даже лишний вызов метода не сделаешь, т.к. под стек всего 256 байт отводится. Вот и получается, что
E>Java-приложение для такой платформы имеет с Java-приложением для другой платформы общего только название Java.

Не надо ничего брать, достаточно не путать твёрдное с круглым, причём мне тоже

Существует спецификация языка java
http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html

Cуществует спецификация виртуальной машины
http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html

и

Существуют стандарты J2SE, J2EE, J2ME и что-то там для карт, — вот они как раз,
не являются стандартом языка, это стандарты библиотек.

Процитированная вами фраза: "Write once, run everywhere", относится к языку java и его байткоду.
Например, я могу написать и скомпилировать j2me-приложение на PC, там же могу его запустить и потестировать, и
и, абсолютно ничего не меняя, я могу запустить полученный код на телефоне.

Всё!

Если приложение требует 150мб памяти, а есть только 10кб — это не значит, что оно стало зависить от платформы, оно стало зависеть от параметров этой платформы, а именно от количества доступной памяти

Но никто ведь и не обещал чудес?

Думаю каждый понимает, что если приложению А, требуется библиотека Б, а её нет, то приложение А работать не станет.
Тут уже речь идёт не о переносимости, а о чём-то другом, более печальном

Аналогичную ситуацию мы получаем, когда пытаемся запустить приложения требующее j2ee библиотек с j2me библиотеками

Или приложение использующее библиотеку телефона сименс в телефоне нокиа

Я уверен, что не открыл для вас ничего нового о java.
Единственное в чём мы расходимся — это в трактовке "Write once, run everywhere".

В этом сообщении я, как мог, прокомментировал свои предыдущие слова:
NG> Ну отчего же, если не путать желаемое с предлагаемым, то вполне себе правильный слова.
NG> Так оно на практике и есть.

E>Тоже самое можно сказать и о C/C++. Пока ты пользуешься STL/stdlibc -- твои программы вполне себе переносимы. А взял FindFirst вместо opendir -- все, кроссплатформенность кончилась.

Только их ещё компилировать нужно для этого

Т.е. вам придётся найти исходники всех сторонних библиотек, которыми вы пользовались и тоже пересобрать

Или написать самим с нуля.

^^^ Это если отвлечься на практическую сторону дела, которая делают такую кроссплатформенность скорее номинальной,
чем реальной, по сравнению с той же java.

А теоретически — да, сначала "вполне себе", а потом — "кончилась"

E>А стандарт C++ по-твоему -- это "теоритический" стандарт?

Какой-то там ISO C++0x %)

E>В такой же ситуации находится и Java, если брать Sun Java и GNU Java Compiler.
E>Или C# от MS или Mono, или DotGNU.

В такой, да не совсем.

Sun сертифицирует реализации своих стандартов и не допускает к жизни и комерческому распространению
"кривые реализации" своих спецификаций, одновременно с этим предлагая свои реализации: бесплатные и сделанные на достаточно высок уровне, за что sun'у большой респект.
Ситуация, когда один компилятор считает так, а другой этак — ноненс.

Кстати, gcj — он и есть GNU Java Compiler? — к моему удивлению оказался медленнее sun реализации j2se,
к тому же он живёт всё ещё на уровне java1.2, поддерживая её в не полном виде %)
Его можно называть "сужением" языка, но никак не "платформеннозависимым или любым другим расширением", как это имело место быть с С++ (прости господи, за упоминание в суе этого славного языка)

Но речь не об этом.

Что бы понять о чём речь придётся напрячься и вспомнить о какой "ситуации" шла речь.

Вспомнил.

Мы говорили о путанице вызваемой наличием разных смыслов у одного слова.
В нашем случае — это наличие несколько компиляторов (причём достаточно поплуярных) для С++ расширяющих
его самым не кроссплатформенным образом,
после чего он делается не кроссплатформенным, а просто хорошим языком

Да, вы правы, и java и с# оказываются в похожей ситуации, только масштаб другой.
Согласитесь, общественность не сильно озаботится, если я напишу кривую jvm для java? %)
У java есть Sun c референсной реализацией спецификаций, у C# — вообще только одна
полная реализация спецификаций — от микрософт (моно — всё ещё не поддерживает спецификацию целиком
и давайте не будем кривить душой, .net никогда не слезет с win %))

Странный у нас получается разговор. Не понятно про что

Здравствуйте, VladD2, Вы писали:

VD>Все. Дальше можно не рассуждать. Импортирвется не часть языка, некий модуль. А ты попробу импортирвуй новую синтаксическую конструкцию.

Дык, как раз таки в результате импорта SYSTEM появляется возможность использовать новые синтаксические конструкции (смотри, например, BlackBox).

Здравствуйте, NotGonnaGetUs, Вы писали:

NGG>Странный у нас получается разговор. Не понятно про что

Имхо, ты просто подтвердил, что суть не столько в кроссплатформенности языков, сколько в кроссплатформенности написанных на этих языках программ (это про j2ee программу и j2me программу, которые без своих платформ работать не будут).

Кстати, не некоторые SIM карты нельзя заливать Java-вский байт-код -- нужно специальными препроцессорами получить найтив код для этой SIM-ки, и именно этот нейтив код заливать. Ну это так, к слову.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Сергей Губанов, Вы писали:

VD>>Все. Дальше можно не рассуждать. Импортирвется не часть языка, некий модуль. А ты попробу импортирвуй новую синтаксическую конструкцию.

СГ>

Дык, как раз таки в результате импорта SYSTEM появляется возможность использовать новые синтаксические конструкции (смотри, например, BlackBox).

Ну блин, неужели их здесь коротко пречислить нельзя было?! Вот взял бы и написал: без SYSTEM case писать нельзя, а вот с SYSTEM, кроме case, мы еще elsif получаем. Посмотреть на такие фокусы мне интересно, а вот лазить, искать какой-то BlackBox -- времени нет. Я лучше с Павлом Дворкиным понастальгирую.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, eao197, Вы писали:

E>Имхо, ты просто подтвердил, что суть не столько в кроссплатформенности языков, сколько в кроссплатформенности написанных на этих языках программ (это про j2ee программу и j2me программу, которые без своих платформ работать не будут).

Вот же как получается.

А хотел сказать только одно: пример про j2ee и j2me — не корректен.
И не имеет к переносимости и кроссплатформенности никакого отношения.

Просто этим приложениям нужны разные библиотеки...

Здравствуйте, eao197, Вы писали:

E>Ну блин, неужели их здесь коротко пречислить нельзя было?

Появляется возможность писать системные флаги SysFlag, машинные инструкции, обертки над win32 dll-ками и т.п.

Type     =    Qualident
        | ARRAY ["[" SysFlag "]"] [ConstExpr {"," ConstExpr}]
            OF Type 
        | RECORD ["[" SysFlag "]"] ["("Qualident")"] FieldList
            {";" FieldList} END
        | POINTER ["[" SysFlag "]"] TO Type
        | PROCEDURE [FormalPars].
ProcDecl    =    PROCEDURE ["[" SysFlag "]"] [Receiver] IdentDef
            [FormalPars] ";"
        DeclSeq [BEGIN StatementSeq] END ident.
FPSection    =    [VAR ["[" SysFlag "]"]] ident {"," ident} ":" Type.
SysFlag    =    ConstExpr | ident.

Для машинных инструкций:

ProcDecl    =    PROCEDURE "[" SysFlag "]" IdentDef [FormalPars]
            [ConstExpr {"," ConstExpr}] ";".

Обертка для win32 dll-ки:

Module     =    MODULE ident ["[" SysString "]"] ";"
        [ImportList] DeclSeq  [BEGIN StatementSeq] END ident ".".
ProcDecl    =    PROCEDURE ["[" SysFlag "]"] [Receiver]
        IdentDef ["[" [SysString ","] SysString "]"] [FormalPars] ";"
        DeclSeq [[BEGIN StatementSeq] END ident].
SysString    =    string.

Дарней wrote:

> C>Ну можно в спеку самого языка еще добавить 20 страниц "Language support
> C>library". Все равно до C# не дотягивает.
> То есть вот это, например:
> 18.4 Dynamic memory management 337
> уже не является частью описания языка? Лихо ты с ним обошелся

Я же сказал, что еще можно добавить 20 страниц Language support library.

> C>Экспорт шаблонов — это не сверхсуперсложная фича, просто для ее
> C>реализации приходилось менять само ядро компилятора.
> ну да, ввести четвертую стадию обработки кода — прелинкер.
> всего навсего

Так и делают.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

Здравствуйте, VladD2, Вы писали:

VD>Зачатки ООП появились в Оберон 2. А это произошло несколько позже.

Кстати, для тех кто по разным причинам не в курсе о чем речь и им не понятно почему VladD2 отказывается видеть в Oberon-1 признаки ООП языка надо заметить, что разница между Oberon-1 и Oberon-2 в этом смысле состоит в следующем:
В Oberon-1 динамический полиморфизм реализован посредством процедурных переменных, а в Oberon-2 динамический полиморфизм реализован посредством процедур связанных с типом (так называемых виртуальных функций).

Вот пример на Oberon-1:

MODULE Oberon1;

  TYPE
    Object* = POINTER TO RECORD
      handler-: Handler;
      (*...*)
    END;

    Message* = RECORD END;

    Handler* = PROCEDURE(obj: Object; VAR msg: Message);


  PROCEDURE Handle (obj: Object; VAR msg: Message);
  BEGIN 
    (* ... *)
  END Handle;

  PROCEDURE NewObject (VAR obj: Object);
  BEGIN
    NEW(obj);
    obj.handler := Handle;
    (*...*)
  END NewObject;

END Oberon1.

А вот аналогичный пример на Oberon-2 (с использованием процедуры связанной с типом):

MODULE Oberon2;

  TYPE
    Object* = POINTER TO RECORD
      (*...*)
    END;

    Message* = RECORD END;


  PROCEDURE (obj: Object) Handle* (VAR msg: Message);
  BEGIN 
    (* ... *)
  END Handle;

  PROCEDURE NewObject (VAR obj: Object);
  BEGIN
    NEW(obj);
    (*...*)
  END NewObject;

END Oberon2.

Собственно, вот такая вот разница.

Для полноты картины аналогичный код на Component Pascal:

MODULE ComponentPascal;

  TYPE
    Object* = POINTER TO EXTENSIBLE RECORD
      (*...*)
    END;

    Message* = RECORD END;


  PROCEDURE (obj: Object) Handle* (VAR msg: Message), NEW, EXTENSIBLE;
  BEGIN 
    (* ... *)
  END Handle;

  PROCEDURE NewObject (VAR obj: Object);
  BEGIN
    NEW(obj);
    (*...*)
  END NewObject;

END ComponentPascal.

Отличие от Oberon-2 заключается в явно прописанных словах: NEW и EXTENSIBLE.

Oberon-1 является подмножеством Oberon-2, а Oberon-2 с некими оговорками подмножеством Component Pascal.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Для полноты картины аналогичный код на Component Pascal:

Извиняюсь, забыл исправить тип Message, должно быть так:

    Message* = ABSTRACT RECORD END;

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Появляется возможность писать системные флаги SysFlag, машинные инструкции, обертки над win32 dll-ками и т.п.

<...кусок грамматики поскипан...>

Нифига не понятно. Как вообще в этом разобраться, если нет грамматик для FieldList, IdentDef, FormalPars, DeclSeq, StatementSeq.

Сергей, а по-человечески можно? Ну фрагмент программы что-ли, или объяснение на пальцах. А то приведенная тобой часть формальной грамматики для меня не сильно отличается от:

(смотри, например, BlackBox)

К тому же из того, что ты привел как-то новых конструкций и не видно. По твоим словам выходило чуть ли, что без SYSTEM в Oberon нет оператора case, а вот с SYSTEM есть. А на поверку -- аналоги __declspec или __asm из C++.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Кстати, для тех кто по разным причинам не в курсе о чем речь и им не понятно почему VladD2 отказывается видеть в Oberon-1 признаки ООП языка надо заметить, что разница между Oberon-1 и Oberon-2 в этом смысле состоит в следующем:
СГ>В Oberon-1 динамический полиморфизм реализован посредством процедурных переменных, а в Oberon-2 динамический полиморфизм реализован посредством процедур связанных с типом (так называемых виртуальных функций).

СГ>Вот пример на Oberon-1:
СГ>

СГ>  PROCEDURE NewObject (VAR obj: Object);
СГ>  BEGIN
СГ>    NEW(obj);
СГ>    obj.handler := Handle;
СГ>    (*...*)
СГ>  END NewObject;
СГ>

СГ>А вот аналогичный пример на Oberon-2 (с использованием процедуры связанной с типом):
СГ>

СГ>MODULE Oberon2;
СГ>  PROCEDURE NewObject (VAR obj: Object);
СГ>  BEGIN
СГ>    NEW(obj);
СГ>    (*...*)
СГ>  END NewObject;
СГ>

СГ>Собственно, вот такая вот разница.

Ага, всего лишь есть поддержка ООП средствами языка, или нет ее.

... << RSDN@Home 1.1.4 stable rev. 510>>

Здравствуйте, eao197, Вы писали:

E>Нифига не понятно. Как вообще в этом разобраться, если нет грамматик для FieldList, IdentDef, FormalPars, DeclSeq, StatementSeq.

Эти штуки взяты из основной грамматики, а системные флаги такие:

System flags for record types

Name    Value    Description
untagged    1    No type tag and no type descriptor is allocated.
        The garbage collector ignores untagged variables.
        NEW is not allowed on pointers to untagged variables.
        No type-bound procedures are allowed for the record.
        Pointers to untagged record type or extensions of this
        record type inherit the attribute of being untagged.
        The offsets of the fields are aligned to
        MIN(4-byte, size), where size is the size of the field.
        The size of the record and the offsets of the fields are
        aligned to 32-bit boundaries.
noalign    3    Same as untagged but without alignment.
align2    4    Same as untagged but with
        MIN(2-byte, size) alignment. 
align8    6    Same as untagged but with
        MIN(8-byte, size) alignment. 
union    7    Untagged record with all fields allocated at offset 0.
        The size of the record is equal to the size of the
        largest field.
        Used to emulate C union types.

System flags for array types
Name    Value    Description
untagged    1    No typetag and no type descriptor is allocated.
        The garbage collector ignores untagged variables.
        NEW is not allowed on pointers to untagged variables.
        Pointers to this array type inherit the attribute of
        being untagged.
        Only one-dimensional untagged open arrays
        are allowed.
        For open untagged arrays, index bounds are
        not checked.

System flags for pointer types
Name    Value    Description
untagged    1    Not traced by the garbage collector.
        No type-bound procedures are allowed for the pointer.
        Must point to an untagged record.

System flags for VAR parameters
Name    Value    Description
nil    1    NIL is accepted as formal parameter.
        Used in interfaces to C
        functions with pointer type parameters.

System flags for procedures
Name    Value    Description
code    1    Definition of a Code procedure (see below).
ccall    -10    Procedure uses CCall calling convention.

E>Сергей, а по-человечески можно? Ну фрагмент программы что-ли, или объяснение на пальцах.

    PROCEDURE [code] Sqrt (x: REAL): REAL        (* Math.Sqrt *)
        0D9H, 0FAH;            (* FSQRT *)

    PROCEDURE [code] Erase (adr, words: INTEGER)    (* erase memory area *)
        089H, 0C7H,            (* MOV EDI, EAX *)
        031H, 0C0H,            (* XOR EAX, EAX *)
        059H,            (* POP ECX *)
        0F2H, 0ABH;            (* REP STOS *)

MODULE MyInterface ["MyDll"];
    PROCEDURE Proc1*;                (* Proc1 from MyDll *)
    PROCEDURE Proc2* ["BlaBla"];                (* BlaBla from MyDll *)
    PROCEDURE Proc3* ["OtherDll", ""];                (* Proc3 from OtherDll *)
    PROCEDURE Proc4* ["OtherDll", "DoIt"];                (* DoIt from OtherDll *)
END MyInterface.

    RECORD [noalign]    (* untagged, size = 7 bytes *)
        c: SHORTCHAR;    (* offset 0, size = 1 byte *)
        x: INTEGER;    (* offset 1 , size = 4 bytes *)
        i: SHORTINT    (* offset 5, size = 2 bytes *)
    END

MODULE Ddraw ["DDRAW.DLL"];

TYPE
  GUID = ARRAY 4 OF INTEGER;

  PtrIUnknown = POINTER TO RECORD [untagged]
    vtbl: POINTER TO RECORD [untagged]
      QueryInterface: PROCEDURE (this: PtrIUnknown; IN iid: GUID; OUT obj: PtrIUnknown): INTEGER;
      AddRef: PROCEDURE (this: PtrIUnknown): INTEGER;
      Release: PROCEDURE (this: PtrIUnknown): INTEGER;
    END
  END;

  PtrDirectDraw = POINTER TO RECORD [untagged]
    vtbl: POINTER TO RECORD [untagged]
      QueryInterface: PROCEDURE (this: PtrDirectDraw; IN iid: GUID; OUT obj: PtrIUnknown): INTEGER;
      AddRef: PROCEDURE (this: PtrDirectDraw): INTEGER;
      Release: PROCEDURE (this: PtrDirectDraw): INTEGER;
      Compact: PROCEDURE (this: PtrDirectDraw): INTEGER;
      ...
      SetCooperativeLevel: PROCEDURE (this: PtrDirectDraw; w, x: INTEGER): INTEGER;
      ...
    END
  END;

PROCEDURE DirectDrawCreate* (IN guid: GUID; OUT PDD: PtrDirectDraw; outer: PtrIUnknown) : INTEGER;

END Ddraw.

MODULE GDI ["GDI32"];

    CONST
        WhiteBrush* = 0; BlackBrush* = 4; NullBrush* = 5;
        WhitePen* = 6; BlackPen* = 7; NullPen* = 8;
        PSSolid* = 0; PSDash* = 1; PSDot* = 2;

    TYPE
        Bool* = INTEGER;
        Handle* = INTEGER;
        ColorRef* = INTEGER;
        Point* = RECORD [untagged] x*, y*: INTEGER END;
        Rect* = RECORD [untagged] left*, top*, right*, bottom*: INTEGER END;

    PROCEDURE CreatePen* (style, width: INTEGER; color: ColorRef): Handle;
    PROCEDURE CreateSolidBrush* (color: ColorRef): Handle;
    PROCEDURE GetStockObject* (object: INTEGER): Handle;
    PROCEDURE SelectObject* (dc, obj: Handle): Handle;
    PROCEDURE DeleteObject* (obj: Handle): Bool;
    PROCEDURE Rectangle* (dc: Handle; left, top, right, bottom: INTEGER): Bool;
    PROCEDURE SelectClipRgn* (dc, rgn: Handle): INTEGER;
    PROCEDURE IntersectClipRect* (dc: Handle; left, top, right, bottom: INTEGER): INTEGER;
    PROCEDURE SaveDC* (dc: Handle): INTEGER;
    PROCEDURE RestoreDC* (dc: Handle; saved: INTEGER): Bool;

END GDI.

	От:	Cyberax
	Дата:	05.10.05 10:52
	Оценка:	+1

	От:	Cyberax
	Дата:	05.10.05 11:01
	Оценка:

	От:	Cyberax
	Дата:	05.10.05 11:04
	Оценка:

	От:	NotGonnaGetUs
	Дата:	05.10.05 11:04
	Оценка:

	От:	Дарней
	Дата:	05.10.05 11:22
	Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	05.10.05 11:57
Оценка:

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	05.10.05 13:42
Оценка: