User Tag List

Страница 4 из 18 ПерваяПервая 12345678 ... ПоследняяПоследняя
Показано с 31 по 40 из 320

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

Комбинированный просмотр

Предыдущее сообщение Предыдущее сообщение   Следующее сообщение Следующее сообщение
  1. #1

    Регистрация
    14.01.2005
    Адрес
    Таганрог, Россия
    Сообщений
    4,286
    Спасибо Благодарностей отдано 
    9
    Спасибо Благодарностей получено 
    91
    Поблагодарили
    39 сообщений
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от elf/2
    где в амижном подходе ооп? где там наследование и инкапсуляция? какие такие тормоза?
    Имеется в виду, что ООП тормоза, но есть и преимущества, а подход амиги- тормоза (как и в ООП), но нет преимуществ, перевешивающих тормоза.

    Цитата Сообщение от elf/2
    так и хочется запретить книги про ООП
    Не надо %) ООП это хорошо (при правильном использовании конечно).

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

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

  2. #1
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  3. #2

    Регистрация
    04.09.2006
    Адрес
    Краснодар
    Сообщений
    58
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    0
    Поблагодарили
    0 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от captain cobalt
    Попробуем сформулировать тезисы по результатам темы:

    1. Подход библиотек Амиги - это тормоза ООП без преимуществ ООП.
    Уважаемый captain cobalt, скажите, вы вживую видели 'подход библиотек Амиги'? Я что-то сомневаюсь... Вы вон давеча ажно драйвер памяти аласма записали в ООП или куда там. Признайтесь, вы даже его в глаза не видели?!

  4. #3

    Регистрация
    13.03.2005
    Адрес
    Пермь
    Сообщений
    294
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    0
    Поблагодарили
    0 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от elf/2
    где в амижном подходе ооп? где там наследование и инкапсуляция? какие такие тормоза?
    Это не ООП. Это только тормоза ООП. Без наследования и инкапсуляции.

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

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

    Но если полиморфизм - это силища ого-го , то у Амиги "просто библиотеки".
    Цитата Сообщение от elf/2
    вызов функции по таблице - это не полиморфизм
    Зато полиморфизм - это (часто и помимо прочего) вызов функции по таблице.
    Цитата Сообщение от elf/2
    ребята, ну давайте не будем бросаться терминами! особенно если они не однозначные и все их понимают по-своему. а уж если ругаем чего-нибудь, то хотя бы с аргументами
    Хорошо. Всегда готов.

  5. #4

    Регистрация
    04.09.2006
    Адрес
    Краснодар
    Сообщений
    58
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    0
    Поблагодарили
    0 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от captain cobalt
    Тормоза на загрузку хэндла в регистр, косвеную передачу управления, и недоступность регистра для передачи аргументов.
    Вы в жизни не видели процессоры архитектуры 68к, вам мало 15 32-битных регистров? Это вам не х86, где каждый регистр на вес золота.

    Кроме того, извольте продемонстрировать тормоза вызовов библиотек амиги, не будьте голословным!
    Например так:
    Код:
       jsr  _LVOFunctionName(a6) ; тут безусловно тормоза, целых 2 слова выбираются из памяти, по сравнению с
       jsr  absolute_address ; абсолютным вызовом, где один только адрес занимает 2 слова
    то у Амиги "просто библиотеки".

  6. #5

    Регистрация
    04.09.2006
    Адрес
    Краснодар
    Сообщений
    58
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    0
    Поблагодарили
    0 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от captain cobalt
    Но если полиморфизм - это силища ого-го , то у Амиги "просто библиотеки".
    Кстати, уважаемый captain cobalt, раз уж вы замечены в бытности 'одептом ООП', зачитайте вот это:

    Код:
    Boopsi is an acronym for Basic Object Oriented Programming System for
    Intuition.  Using the Object Oriented Programming (OOP) model, Boopsi
    represents certain Intuition entities, like Gadgets and Images, as objects.
    
    There are many advantages to using Boopsi:
    
      * Boopsi makes Intuition customizable and extensible.  Boopsi
        programmers can create new types of Boopsi objects to suit the needs
        of their applications.  These new types of objects are part of
        Intuition and can be made public so other applications can use them.
        Because applications can share the new types, application writers
        don't have to waste their time duplicating each other's efforts
        writing the same objects.
    
      * New types of Boopsi objects can build on old types of Boopsi objects,
        inheriting the old object's behavior.  The result is that Boopsi
        programmers don't have to waste their time building new objects from
        scratch, they simply add to the existing object.
    
      * OOP and Boopsi apply the concept of interchangeable parts to
        Intuition programming.  A Boopsi programmer can combine different
        Boopsi objects (like gadgets and images) to create an entire
        Graphical User Interface (GUI).  The Boopsi programmer doesn't have
        take the time to understand or implement the inner workings of these
        objects.  The Boopsi programmer only needs to know how to interact
        with Boopsi objects and how to make them interact with each other.
    
      * Boopsi objects have a consistent, command-driven interface.  To the
        Boopsi programmer, there is no difference between displaying a text,
        border, or bitmap-based Boopsi image, even though they are rendered
        quite differently.  Each image object accepts a single command to
        tell it to render itself.
    
    Before reading this chapter, you should already be familiar with several
    Amiga concepts.  Boopsi is built on top of Intuition and uses many of its
    structures.  These include Intuition gadgets, images, and windows.  Boopsi
    also uses the tag concept  to pass parameters.  The "Utility Library"
    chapter of this manual discusses tags.  The "Utility Library" chapter also
    discusses callback Hooks, which are important to the later sections of
    this chapter.
    
     OOP Overview               Boopsi Gadgets 
     Creating a Boopsi Class    Function Reference
    Заметьте, и это на Амиге, на которой якобы 'просто библиотеки'. И не имеет никакого отношения к 'цэ-крест-крест', так как имеет место быть не в конструкциях языка, а на самом деле.
    И на основе этой технологии написан MUI - очень замечательный и удобный оконный-графический амижный интерфейс.

  7. #6

    Регистрация
    13.03.2005
    Адрес
    Пермь
    Сообщений
    294
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    0
    Поблагодарили
    0 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от elf/2
    в моих книгах ООП=наследование+инкапсуля ция+полиморфизм.
    Это правильно. Но это всего-лишь определение ООП. Если пользоваться только определением, ничего хорошего не получится.

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

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

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

    Как же всё-таки проектировать ООП программы? Об этом рассказывается совсем в других книгах. И обсуждается это не скатываясь на определения.
    Цитата Сообщение от elf/2
    соответсвенно "неявный" вызов возможен только для явных потомков. в случае фара этим даже не пахнет
    ООП - это неявное использование функциональности.

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

    Как же выразить плагины в ООП? Очень просто: все плагины должны наследовать от одного абстрактного класса плагина.
    Цитата Сообщение от elf/2
    пять пунктов ничем не пропитано

    если Вы говорите что ООП данные ограничения/проблемы позволяет обойти то я удовольствием послушаю как
    Всё очено просто: клиенты базового класса могут динамически компоноваться с реализациями производных классов.
    Цитата Сообщение от elf/2
    вот только объяснение про "сферический компоновщик в вакуме" это не объяснение. это демагогия на мой взгляд. потому что:
    1. кто компоновщика будет загружать?
    Это не имеет значения.

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

    Но коль скоро динамический компоновщик загружен в память, он может сидеть там сколь угодно долго. И динамически компоновать сколь угодно много.
    Цитата Сообщение от elf/2
    2. кто ему расскажет что нужно грузить?
    А это не его дело что-либо грузить. Его дело компоновать то что ему дают. Откуда загрузилось то что ему дают компоновать - это тоже не его дело.

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

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

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

  8. #7

    Регистрация
    14.01.2005
    Адрес
    N.Novgorod
    Сообщений
    803
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    1
    Поблагодарили
    1 сообщение
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

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

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

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

  9. #8

    Регистрация
    02.02.2006
    Адрес
    Voronezh
    Сообщений
    94
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    0
    Поблагодарили
    0 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

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

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

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

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

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

  10. #9

    Регистрация
    14.01.2005
    Адрес
    Таганрог, Россия
    Сообщений
    4,286
    Спасибо Благодарностей отдано 
    9
    Спасибо Благодарностей получено 
    91
    Поблагодарили
    39 сообщений
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

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

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

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

  11. #10

    Регистрация
    02.02.2006
    Адрес
    Voronezh
    Сообщений
    94
    Спасибо Благодарностей отдано 
    0
    Спасибо Благодарностей получено 
    0
    Поблагодарили
    0 сообщений
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Vitamin
    У меня по этому поводу одна идея- проводить вырезание только нужных функций. Но это требует ресурсов и может быть применено только при окончательной сборке бинарника (не runtime).
    А про CP/M (точнее, реализацию) поподробнее можно?
    Такое я видел в Pascal MT+, т.е. в его библиотеках. При линковке проги со стадартной библиотекой PASLIB.ERL от туда дергались только нужные функции. Как оно там внутри работало - не знаю. Это же закрытые коммерческие продукты. Кроме того, формат ERL - это, по словам разработчиков MT+, улучшенный формат REL, который являлся де-факто стандартом для перемещаемых объектных модулей под CP/M. REL могли генерить некоторые ассемблеры и компиляторы.

    Сам формат REL кажется даже документирован, т.е. где-то описание я встречал, но где - не помню. Скорее всего в документации к dev-средствам от Digital Research.

Страница 4 из 18 ПерваяПервая 12345678 ... ПоследняяПоследняя

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Ответов: 9
    Последнее: 10.11.2024, 08:26
  2. Управление эмулятором из zx-программы
    от Spectre в разделе Эмуляторы
    Ответов: 42
    Последнее: 29.08.2006, 12:58
  3. Кто может помочь в создании программы
    от Лебедев в разделе Люди
    Ответов: 9
    Последнее: 22.07.2006, 09:41
  4. Программы для модемов
    от p@lex в разделе Софт
    Ответов: 21
    Последнее: 11.02.2006, 21:36

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •