Библиотеки-модули-программы...

[Vitamin]

Когда я писал либмана, то Амигу в глаза не видел, так что "содрать" не мог

Не говорю что специально. Да и вообще не вижу ничего зазорного в переносе хороших идей с/на спек.
Основываюсь на словах тов.yoko_ono и acidrain, говорящих что это есть "как в амиге".

[Advertiser]

[captain cobalt]

Попробуем сформулировать тезисы по результатам темы:

1. Подход библиотек Амиги - это тормоза ООП без преимуществ ООП.
2. Для Speccy лучше всего подход с пропатчиванием CALL клиента.
3. Косвенные переходы следует использовать для полиморфизма.

[elf/2]

Надо разбираться в ООП. Рекомендую книгу.

видимо мы читали разные книги...

Процедурное программирование - это явное использование функциональности процедур. Например, для вывода спрайта используется процедура вычисления адреса в видеопамяти. При этом точно известно, что от неё ожидать, у программиста имеется реализация этой процедуры.

Теперь посмотрим на FAR с плагинами. FAR, очевидно, явно загружает их с помощью LoadLibrary. При этом разработчики FAR не знают, что реализовано в плагине. Они лишь надеются что это нечто полезное. Это неявное использование функциональности.

(забавное сочетание: явное использование функциональности - неявная загрузка DLL; неявное использование - явная загрузка)

в моих книгах ООП=наследование+инкапсуля ция+полиморфизм. и соответсвенно "неявный" вызов возможен только для явных потомков. в случае фара этим даже не пахнет.

фар определяет и использует плагины на основании списка функций, это не ООП. это ближе всего к duck typing которая активно используется в новомодных языках (python, ruby)

тогда уж:
#include "stdio.h"
printf(...)
тоже ООП такая программа могла быть написана много лет назад, а работает до сих пор с новыми версиямя libc. причем за годы существования проги libc могла поменяться очень сильно включая новую функциональность

ИМХО о пяти пунктах насквозь пропитано духом процедурного программирования. "Чтобы был динамический компоновщик, нужно чтобы сначала была ось". Это не так. ООП даёт механизм преодоления. FAR запросто может использовать плагины, которых не существовало во время его написания.

пять пунктов ничем не пропитано я описал те проблемы которые динамическая загрузка библиотек имеет на текущий момент для спека. а уж про то что для динамической компоновки обязательно нужна ось я точно не говорил если Вы говорите что ООП данные ограничения/проблемы позволяет обойти то я удовольствием послушаю как

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

вот только объяснение про "сферический компоновщик в вакуме" это не объяснение. это демагогия на мой взгляд. потому что:
1. кто компоновщика будет загружать?
2. кто ему расскажет что нужно грузить?

[elf/2]

так и хочется запретить книги про ООП

1. Подход библиотек Амиги - это тормоза ООП без преимуществ ООП.

где в амижном подходе ооп? где там наследование и инкапсуляция? какие такие тормоза?

3. Косвенные переходы следует использовать для полиморфизма.

какой на*рен полиморфизм на спекке? вызов функции по таблице - это не полиморфизм

ребята, ну давайте не будем бросаться терминами! особенно если они не однозначные и все их понимают по-своему. а уж если ругаем чего-нибудь, то хотя бы с аргументами

[elf/2]

Вот именно - в отдельной части EXE хранится список ячеек, в которые надо подставить абсолютные адреса этих функций в момент приведения EXE в работоспособный вид (при загрузке), и создание таких списков - штатная функция генераторов кода на пц.
...
Варианты Shaos'а и мой свободны от любой модификации абсолютных адресов вызовов библиотечных функций в user-программе.

перечитайте пожалуйста мое исходное сообщение. EXE не патчится и либа кстати тоже.
1. в заголовке exe файла находится список jmp'ов
2. все call'ы идут на них
3. когда система загрузит exe+dll она исправляет адреса в этих JMP'ах. ни один байт внутри программы не изменяется!

если я плохо объясняю, то посмотрите в MSDN он в отличии от амижных доков находиться в открытом доступе.

более того, если dll без base relocation (т.е. грузиться по фиксированным адресам) то внутри exe все call'ы идут сразу в библиотеку без дополнительного jmp'а. причем все это делает линкер автоматом при сборке программы, руками делать ничего не надо

[Vitamin]

где в амижном подходе ооп? где там наследование и инкапсуляция? какие такие тормоза?

Имеется в виду, что ООП тормоза, но есть и преимущества, а подход амиги- тормоза (как и в ООП), но нет преимуществ, перевешивающих тормоза.

так и хочется запретить книги про ООП

Не надо %) ООП это хорошо (при правильном использовании конечно).

Если уж говорить о полиморфизме в применении к плагинам, то делают так, как я рассказал ранее- экспортируется одна-единственная функция фабрики классов, которая инстанциирует потомки класса-интерфейса. А вот при вызове уже чистый полиморфизм получается.

Вернусь к теме разговора. Для чего все начинал? У меня есть моя та самая библиотека модулей. Я ее планирую применить в некоторых своих проектах. В то же время, не вредно помечтать (см. первый пост). Если народ хочет поддержать идею, то я жду предложений по расширению функциональность (изменять глобально там вроде ничего не надо). А если не надо- то не надо... Буду делать исключительно для себя, для своих целей

[captain cobalt]

где в амижном подходе ооп? где там наследование и инкапсуляция? какие такие тормоза?

Это не ООП. Это только тормоза ООП. Без наследования и инкапсуляции.

Тормоза на загрузку хэндла в регистр, косвеную передачу управления, и недоступность регистра для передачи аргументов.

Те же самые тормоза, что у вызова виртуальной функции.

Но если полиморфизм - это силища ого-го , то у Амиги "просто библиотеки".

вызов функции по таблице - это не полиморфизм

Зато полиморфизм - это (часто и помимо прочего) вызов функции по таблице.

ребята, ну давайте не будем бросаться терминами! особенно если они не однозначные и все их понимают по-своему. а уж если ругаем чего-нибудь, то хотя бы с аргументами

Хорошо. Всегда готов.

[captain cobalt]

в моих книгах ООП=наследование+инкапсуля ция+полиморфизм.

Это правильно. Но это всего-лишь определение ООП. Если пользоваться только определением, ничего хорошего не получится.

Если прочитать определение поэзии, то сразу после этого не станут сразу получаться хорошие стихи.

Если взять из матанализа определение предела функции в точке, то вычислить даже один предел довольно затруднительно. К счастью, для этого имеются гораздо более сподручные средства, такие как "Правило Лопиталя", "Теорема Коши" и ещё вагон всяких разных, которые напрямую не следуют из определения предела.

Как грамотно писать ООП программы. На этот вопрос нет ответа в книгах типа "ООП=наследование+инкапсул� �ция+полиморфизм". Это всё равно что обучать искусству поэзии по принципу: "поэзия - это <...тут определение поэзии...>; вот, например, Пушкин: <...здесь стихи Пушкина...>".

Как же всё-таки проектировать ООП программы? Об этом рассказывается совсем в других книгах. И обсуждается это не скатываясь на определения.

соответсвенно "неявный" вызов возможен только для явных потомков. в случае фара этим даже не пахнет

ООП - это неявное использование функциональности.

Неявное использование функциональности - это не всегда ООП. Но оно всегда может быть выражено в ООП. А раз может, то, по мнению членов "секты ООП", оно должно быть выражено именно так.

Как же выразить плагины в ООП? Очень просто: все плагины должны наследовать от одного абстрактного класса плагина.

пять пунктов ничем не пропитано

если Вы говорите что ООП данные ограничения/проблемы позволяет обойти то я удовольствием послушаю как

Всё очено просто: клиенты базового класса могут динамически компоноваться с реализациями производных классов.

вот только объяснение про "сферический компоновщик в вакуме" это не объяснение. это демагогия на мой взгляд. потому что:
1. кто компоновщика будет загружать?

Это не имеет значения.

Его можно загрузить из boot.B, его можно прошить в ПЗУ. Много чего можно.

Но коль скоро динамический компоновщик загружен в память, он может сидеть там сколь угодно долго. И динамически компоновать сколь угодно много.

2. кто ему расскажет что нужно грузить?

А это не его дело что-либо грузить. Его дело компоновать то что ему дают. Откуда загрузилось то что ему дают компоновать - это тоже не его дело.

Кто же будет грузить то что надо компоновать? Грузить может, например, #3D13, который всегда доступен.

Но кто же будет говорить #3D13, что надо грузить? Что ж. Придётся написать маленькую программу, которая будет делать это. С пользовательским интерфейсом. И назвать её "файловый менеджер". Более того, поскольку есть динамический компоновщик, то можно скомпоноваться с (собственноручно загруженным) драйвером HDD, а затем грузить модули с HDD.

По функциональности уже ОСь получается, хотя казалось бы, динамический компоновщик...

[captain cobalt]

EXE не патчится и либа кстати тоже.

Здесь нужно уточнить, что на x86 команды прямых CALL и JMP - относительные. Относительно счётчика команд. Если код использует внутри себя только такие переходы, то он перемещаем без пропатчивания.

[captain cobalt]

Если народ хочет поддержать идею, то я жду предложений по расширению функциональность

Вот такие предложения:

1. Динамический компоновщик и библиотеки должны оставаться в памяти как можно дольше без лишних повторных загрузок с диска. Тогда и ось сможет "нарасти".

2. Нужен контроль целостности. Например, на основе строки с перечислением аргументов. Если импортированный и экспортированный интерфейс не совпадают, нужно сообщение об ошибке.

3. Нужна единообразная инструментальная поддержка для статической и динамической компоновки. Чтобы из одних и тех же исходников можно было компоновать как динамически так и статически.

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