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

[Vitamin]

Примерно этого я и ждал вот уже 13 страниц %))

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

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

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

Ну простейший контроль само собой- если в собранной программе остались неразрешенными некоторые внешние ссылки, она считается невалидной. Равно как и если есть две и более точки с одним и тем же именем (для универсальности- сигнатурой). Плюс конечно версионный контроль

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

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

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

Ну простейшее- математика, графика, дисковые операции. А в дальнейшем- каждый может писать свои и выкладывать их.

[elf/2]

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

вот и я о том же либо компоновщик - часть "оси", либо статически слинкован с программой

а про ООП в этом треде надо завязывать, imho. пока нет языка с явной поддержкой по крайней мере...

да и вообще сравнивать ООП с библиотеками - не корректно. т.к. лежат они на совершенно разных уровнях.

одна беда в этом треде: слишком все эмоционально, и надо бы его уже на два-три делить
1. статическая линковка из объектников (Витамин предложил): как это сделать на спекки оптимально
2. динамическая линковка: изложить и сравнить существующие подходы (амми/libman/Win/Lin/etc.) и в результате выбрать/синтезировать то что для спека лучше подходит
3. ооп и иже с ним (лучше сразу во флейм)

[maximk]

Ребят, а на самом деле - стоит ли оно того?

Посмотрим еще раз на плюсы:
1) экономия места. Но кого оно волнует из эмуляторщиков (а их большинство)? Да и реальщики стараются подрубить винт или флешку.
2) исправление ошибки в библиотеке устраняет оную во всех зависимых программах.

Но как правильно было замечено, (2) одновременно ведет и к гораздо бОльшей проблеме, то что в винде было названо DLL-hell. Ладно там ошибку исправить, а как быть, когда в результате эволюции наступает этап, когда требуется изменение интерфейса функции? Ресурсы спектрума уж очень скромны, чтобы решать такие задачи, где даже у старших братье все до сих пор не все гладко.

И еще. В спектрум-среде за все это время как-то не сложилась практика использования общих библиотек, думаете когда сообщество стало гораздо менее многочисленным есть еще шансы?

Частично проблемы общих библиотек решаются с появление нормальной ОСи. Ведь тогда ввод-вывод уже будет поддержан ядром, а это основное, где могут присутствовать обшие куски. Второе - UI-core - но его почти всегда каждый предпочитает делать по-своему.

Имхо, гибкий инстурмент подключения библиотек во время компоновки был бы более уместен. Кстати, в CP/M такое было. В том числе там можно было подключить из бибилиотеки к модулю прямо конкретную функцию, а не всю либу.

[captain cobalt]

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

Как только что показано, загрузка и компоновка - это разные вещи.
Сборка в момент загрузки - это динамическая компоновка.

Держать библиотеки в памяти наиболее полезно для разработки.

Сейчас для сборки используются include. В однотекстовых ассемблерах при каждой сборке происходит елозенье по диску. В многотекстовых, когда всё в памяти, всё равно имеются тормоза с компиляцией. Если же всё лежит в памяти готовое к употреблению, нужно лишь при компиляции прилинковать один разрабатываемый модуль.

Ну простейший контроль само собой- если в собранной программе остались неразрешенными некоторые внешние ссылки, она считается невалидной. Равно как и если есть две и более точки с одним и тем же именем (для универсальности- сигнатурой).

Вот.
Сигнатура это хорошо и обязательно.

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

Проблема такая.
Есть "старая добрая статическая" сборка через include. Есть "новая крутая динамическая".

Программист смотрит. Если инструментарий отличается, нужно выбирать что использовать. Для старого способа уже есть свой наработанный код. Для нового способа надо переписывать, переделывать почти с нуля. Многие не смогут разобраться в своих собственных старых ассемблерных исходниках.

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

Ну простейшее- математика, графика, дисковые операции. А в дальнейшем- каждый может писать свои и выкладывать их.

Нужно поточнее списочек.

В предыдущих вариантах этой темы высказывались конкретные предложения. Надо их все собрать, упорядочить, углубить, уширить. Опубликовать. Затем программисты поскребут в своих запасах.

да и вообще сравнивать ООП с библиотеками - не корректно. т.к. лежат они на совершенно разных уровнях.

А бывают "библиотеки классов"?

[elf/2]

Сигнатура это хорошо и обязательно.

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

[captain cobalt]

Но как правильно было замечено, (2) одновременно ведет и к гораздо бОльшей проблеме, то что в винде было названо DLL-hell. Ладно там ошибку исправить, а как быть, когда в результате эволюции наступает этап, когда требуется изменение интерфейса функции? Ресурсы спектрума уж очень скромны, чтобы решать такие задачи, где даже у старших братье все до сих пор не все гладко.

Именно поэтому нужен контроль интерфейса не просто по имени, а по сигнатуре.

На заскоки старших братьев конкретно от Microsoft можно не обращать внимания.

И еще. В спектрум-среде за все это время как-то не сложилась практика использования общих библиотек, думаете когда сообщество стало гораздо менее многочисленным есть еще шансы?

Частично проблемы общих библиотек решаются с появление нормальной ОСи. Ведь тогда ввод-вывод уже будет поддержан ядром, а это основное, где могут присутствовать обшие куски. Второе - UI-core - но его почти всегда каждый предпочитает делать по-своему.

Это уже следующий вопрос.

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

Программирование становится намного комфортнее.

Но здесь сейчас опять у кого-нибудь случится истерика.

[Advertiser]

[captain cobalt]

какая-такая проверка сигнатур при динамической линковке? этого даже в винде, где ресурсов много, не делают.

Поправочка.
Не делали.
Теперь, когда DLL hell доканал, придумали новые чудеса техники.

а тем более откуда сигнатуры брать в случае ассемблера?

Прописывать вручную.

[elf/2]

Поправочка. Не делали. Теперь, когда DLL hell доканал, придумали новые чудеса техники.

я слышал что dll hell был связан с несовместимостью версий библиотек... но тем неменее чудеса техники в студию. как теперь с этим борються? уж не предагается ли reflection на спекке делать?

а тем более откуда сигнатуры брать в случае ассемблера?

Прописывать вручную.

фтопку! слишком много ошибок будет и главное не понятно как их потом проверять. тоже руками ?

[Vitamin]

Частично проблемы общих библиотек решаются с появление нормальной ОСи. Ведь тогда ввод-вывод уже будет поддержан ядром, а это основное, где могут присутствовать обшие куски. Второе - UI-core - но его почти всегда каждый предпочитает делать по-своему.

А почему предпочитает? Потому что "кого хочу- не знаю, кого знаю- не хочу". Я вот тоже свой UI писал по мотивам SupremeGUI от DT. Была б она открыта (в то время)- использовал бы ее и все... А будет выбор- будет использование.

Имхо, гибкий инстурмент подключения библиотек во время компоновки был бы более уместен. Кстати, в CP/M такое было. В том числе там можно было подключить из бибилиотеки к модулю прямо конкретную функцию, а не всю либу.

У меня по этому поводу одна идея- проводить вырезание только нужных функций. Но это требует ресурсов и может быть применено только при окончательной сборке бинарника (не runtime).
А про CP/M (точнее, реализацию) поподробнее можно?

Держать библиотеки в памяти наиболее полезно для разработки.

Это уже интимные проблемы компилятора. Будет кешировать- будут в памяти, не будет кешировать- будет елозить по диску.

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

Хранить внутри файла библиотеки. Если жалко места на строку вида
memcpy[сигнатура в бешеном формате], то можно делать хеширование в 3-4 байта и не мучаться. Само собой, линковщик должен это учитывать

[captain cobalt]

я слышал что dll hell был связан с несовместимостью версий библиотек... но тем неменее чудеса техники в студию. как теперь с этим борються? уж не предагается ли reflection на спекке делать?

Например в дотнете сборки контролируются по номеру версии.

На спеке предлагается контроль сигнатур по хэшам.

фтопку! слишком много ошибок будет и главное не понятно как их потом проверять. тоже руками ?

Есть предложение совместить это с системой автодокументирования исходника.

Из исходника компилируется отдельно объектный код, отдельно - документация.

Проверочные хэши генерируются из ключевых кусков документации.

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

Далее работает правило: "если документация, по которой программист писал клиентский код не совпадает с текущей документацией - компоновка не происходит".

Это уже интимные проблемы компилятора. Будет кешировать- будут в памяти, не будет кешировать- будет елозить по диску.

Ну так лучше, если они будут сидеть скомпонованные друг с другом. Сидеть и не двигаться с места. Новый код будет помещаться в свободную память и прикомпоновываться к ним.