Здравствуйте, гость ( Вход | Регистрация )
Iron Bug | Дата 9.6.2011, 11:13 |
возможность расширять одни плагины другими да, идея интересная. но это для каких-то суперизвращённых задач к тому же, моя идея не мешает этому варианту. можно внутри плагина реализовать такую же фигню и так далее. фракталы, блин! а для моих задач работы с железом пока моих протоколов хватает. я много лет работаю с железяками и вряд ли появится что-то, что я не предусмотрела. ибо в хардварном мире всё довольно однотипно и каких-то особых чудес не встречается. |
|
PAFOS | Дата 9.6.2011, 8:05 |
с этими плагинами надо очень быть предусмотрительным) Нередки случаи когда с нужно в очередной раз расширить приложение, а интерфейсы, заложенные в него, уже не способны решить требуемые задачи. Мне тут однажды попалась на глаза программа SharpDevelop (опен сорс IDE для разработки на .Net). У нее мне понравилась система плагинов - там есть возможность расширять одни плагины другими. Очень интересная идея имхо) |
|
Iron Bug | Дата 7.6.2011, 20:27 |
ну, если прога загружает библиотеку и создаёт представитель класса, то она же его и убивает. тут проблем не возникает. единственное, за чем следит сам юзер - это очистка ео локальных переменных и правильное завершение работы после вызова деструктора. на самом деле, для меня это не проблема, потому что я - единственный разработчик "плагинов" для своей софтины проблема в том, что надо уметь динамически, где-то в поле, расширять функционал, без пересборки основной софтины. и эту проблему я решила через такие расширения, которые просто прописываются в конфиге и подгружаются динамически. |
|
PAFOS | Дата 7.6.2011, 8:10 |
Имхо счетчик ссылок тут лишь способ правильного управления временем жизни объекта. * Однако СОМ это ведь не только счетчик ссылок. Клиент (Приложение) знает об интерфейсе IUnknown и знает об интерфейсе, который несет полезную нагрузку. Через IUnknown клиент может узнать поддерживает ли сервер (СОМ объект) нужный ему интерфейс. Так же через IUnknown ведется подсчет ссылок. Но это только вершина айсберга... t;line-height:100%">*Iron Bug, рано или поздно (если будешь развивать эту тему) ты придешь к вопросу о моменте удаления объекта. В данной версии момент удаления объекта определяет программист (правильно ли я понял?), использующий объект, а не программист, разрабатывающий сам объект. Это конечно по нашему, по С++вски, но накладывает на ленивого программиста дополнительные обязанности. |
|
Iron Bug | Дата 6.6.2011, 22:58 |
напоминает технологию COM мелкософта. главная идея COM-объектов - счётчики ссылок. а это обычное наследование, просто реализованное в библиотеках. |
|
PAFOS | Дата 6.6.2011, 16:12 |
напоминает технологию COM мелкософта. | |
Iron Bug | Дата 12.3.2011, 17:28 |
Я тут обнаружила потребность народа в некотором примере насчёт использования динамических библиотек. Вот, вытащила из своего проекта куски, относящиеся к загрузке и вызовам. Смысл примера такой: есть приложение, которое грузит (динамически) библиотеки с некоторым интерфейсом (IInterface). Все загружаемые библиотеки наследуют некоторое дефолтное поведение от базового класса (Base). Если библиотека не реализует какой-то метод интерфейса, то будет вызван базовый метод. Это чтобы не переписывать в каждой библиотеке одни и те же действия. Пример загружаемой библиотеки - Derived. Я привела флаги компиляции и сборки для разных систем (я собираю под линюксом с gcc и icc и под вендой с mingw). Вроде ничего не забыла, но возможно, что некоторые флаги не нужны для данного примера (я их поместила в квадратные скобки [...]). Просто у меня проект большой и там много чего ещё кроме этого, поэтому там могли оказаться не относящиеся к данной подзадаче параметры. Да, стандартные флаги для библиотек типа -ldl я сюда не выписывала. Выписаны только специфические параметры. Какие плюсы? Собственно, независимость библиотек от основного кода. Для добавления функционала достаточно перекомпилять загружаемые модули. Базовый функционал класса Base можно менять, не пересобирая библиотеки, которые его используют. Надеюсь, что в принципе понятно. Общий файл интерфейса Interface.h Раскрывающийся текст
Инструкции по сборке базовой библиотеки Base: gcc,icc: CXXFLAGS: -fPIC LDFLAGS: -nodefaultlibs -shared mingw: для венды установить дефайн__DLL (для экспорта) CXXFLAGS: LDFLAGS: -enable-auto-import [-enable-runtime-pseudo-reloc] -Wl,--kill-at Заголовок базового класса Base.h Раскрывающийся текст
Base.cpp не привожу, он тут не важен. Там можно что-то выполнять, какие-то базовые действия. Инструкции по сборке библиотеки Derived: gcc,icc: CXXFLAGS: -fPIC [-enable-runtime-pseudo-reloc] LDFLAGS: -nodefaultlibs -shared -lBase mingw: для венды установить дефайн __DLL (для экспорта) CXXFLAGS: LDFLAGS: -enable-auto-import [-Wl,--allow-multiple-definition] Заголовок файла основной динамически загружаемой библиотеки Derived.h Раскрывающийся текст
Пример реализации основной динамически загружаемой библиотеки Derived.cpp Раскрывающийся текст
Инструкции по сборке вызывающей программы: gcc,icc: CXXFLAGS: -fPIC LDFLAGS: mingw: CXXFLAGS: LDFLAGS: -enable-auto-import [-enable-runtime-pseudo-reloc] [-Wl,--allow-multiple-definition] -Wl,--kill-at Пример загрузки/выгрузки библиотеки Derived и использования класса (вызов метода init): Раскрывающийся текст
Примечание: при вызове _pInterface->init() будет вызван метод init класса Derived. |
|
Iron Bug | Дата 21.2.2011, 14:45 |
у меня тут кода слишком дофига. проект жирный, много-много библиотек, полная кроссплатформа, буст и надо специально сидеть и выкусывать куски настроек, относящиеся к данной подзадаче. но если кому очень приспичит, могу пошариться и выписать. только не срочно, а то у меня тут большой проект с парсерами и работой с кучей железа. я по уши в работе, днём и ночью. сейчас вот добила интерфейс для ещё одной шины и вылезла в сеть - мозг разгрузить маленько |
|
ViGOur | Дата 19.2.2011, 23:23 |
Сам не писал подобного, но читал статью как подобное реализовать на рсдн, вот только найти не могу, так как давно уже читал. Ты лучше описание кодом как реализовала выложи... |
|
Iron Bug | Дата 15.2.2011, 20:37 |
в общем, ковыряла-ковыряла и решила-таки эту задачу. правда, чуть окольным путём: теперь у меня две библиотеки и основной модуль. в библиотеках - базовый класс и класс-наследник. библиотека наследника линкуется динамической связью с библиотекой базового класса. а основной модуль грузит класс-наследник из библиотеки через dlopen (ну или LoadLibrary под вендой). если потомок не реализует метод, то вызывается метод предка, из базовой библиотеки. всё работает и под вендой, и под линём. правда, пришлось кое-где idfef'ы налепить и с флагами линковки всего этого безобразия повозиться, чтобы работало как надо. и пока создание представителя класса сделано через специальные методы, а не подменой указателей в виртуальных таблицах, хотя можно и напрямую класс грузить из библиотеки, если маленько ассемблера добавить. |
|
Просмотр темы полностью (откроется в новом окне) | |
Текстовая версия | Сейчас: 28.4.2024, 22:33 |