C++. Модульное программирование
Привет всем, кто необошел мою тему.
После некоторых экспериментов я пришел к выводу, что программа построенная на модулях в моих потребностях - это есть самый хороший выбор, т.к. обновлять проще модули, нежели пересобирать весь код.
Так вот вопрос в чем. Я не смог в инете найти уроки (или статьи) азы постороения программ, поддерживающих модули.
Как dll подключать в программе я знаю, но не знаю как сделать так, чтобы основную программу не трогать, а модули чтобы работали. Вот как реализоно это в фотошопе или 3дмаксе...
Есть ли у кого какая инфа по этому поводу?
После некоторых экспериментов я пришел к выводу, что программа построенная на модулях в моих потребностях - это есть самый хороший выбор, т.к. обновлять проще модули, нежели пересобирать весь код.
Так вот вопрос в чем. Я не смог в инете найти уроки (или статьи) азы постороения программ, поддерживающих модули.
Как dll подключать в программе я знаю, но не знаю как сделать так, чтобы основную программу не трогать, а модули чтобы работали. Вот как реализоно это в фотошопе или 3дмаксе...
Есть ли у кого какая инфа по этому поводу?
Цитата:
Originally posted by DissDoc
Привет всем, кто необошел мою тему.
После некоторых экспериментов я пришел к выводу, что программа построенная на модулях в моих потребностях - это есть самый хороший выбор, т.к. обновлять проще модули, нежели пересобирать весь код.
Так вот вопрос в чем. Я не смог в инете найти уроки (или статьи) азы постороения программ, поддерживающих модули.
Как dll подключать в программе я знаю, но не знаю как сделать так, чтобы основную программу не трогать, а модули чтобы работали. Вот как реализоно это в фотошопе или 3дмаксе...
Есть ли у кого какая инфа по этому поводу?
Привет всем, кто необошел мою тему.
После некоторых экспериментов я пришел к выводу, что программа построенная на модулях в моих потребностях - это есть самый хороший выбор, т.к. обновлять проще модули, нежели пересобирать весь код.
Так вот вопрос в чем. Я не смог в инете найти уроки (или статьи) азы постороения программ, поддерживающих модули.
Как dll подключать в программе я знаю, но не знаю как сделать так, чтобы основную программу не трогать, а модули чтобы работали. Вот как реализоно это в фотошопе или 3дмаксе...
Есть ли у кого какая инфа по этому поводу?
Ты имеешь ввиду что-то типа плугинов?
Цитата:
Originally posted by RelB
Ты имеешь ввиду что-то типа плугинов?
Ты имеешь ввиду что-то типа плугинов?
Да. Это по-моему одно и то же. (хотя различия тоже допускаю..) Но мне кажется это тоже самое. Просто в разных местах говорят по разному.
Цитата:
Originally posted by DissDoc
Да. Это по-моему одно и то же. (хотя различия тоже допускаю..) Но мне кажется это тоже самое. Просто в разных местах говорят по разному.
Да. Это по-моему одно и то же. (хотя различия тоже допускаю..) Но мне кажется это тоже самое. Просто в разных местах говорят по разному.
Самый простой способ - COM. Регистрируешь категорию... и создаешь объекты отсосящиеся к этой категории... Затем с помощью объекта StdComponentCategoriesMgr выбираешь то, что тебе нужно...
P.S. Если ничего не понятно :) Читай MSDN - COM Fundamentals - Component Categories Manager Implementation
Твой совет мне ясен, а вот COM для меня загадкой остается, но видно от него никуда не деться )
Цитата:
Originally posted by DissDoc
Твой совет мне ясен, а вот COM для меня загадкой остается, но видно от него никуда не деться )
Твой совет мне ясен, а вот COM для меня загадкой остается, но видно от него никуда не деться )
Можно кончно и без него, но данный подход является наиболее универсальным, как мне кажется...
Можно будет писать плугинчики на всем что угодно...
P.S. COM - если его понять, очень простая и в то же время очень сильная вещь! :)
Механизм механизмом, а еще, как мне кажется, нужно продумать интерфейс взаимодействия с основной программой и модулями непосредственно. Именно с этой задачи и стоит начать.
Цитата:
Originally posted by REmindER
Механизм механизмом, а еще, как мне кажется, нужно продумать интерфейс взаимодействия с основной программой и модулями непосредственно. Именно с этой задачи и стоит начать.
Механизм механизмом, а еще, как мне кажется, нужно продумать интерфейс взаимодействия с основной программой и модулями непосредственно. Именно с этой задачи и стоит начать.
Я более менее продумал уже сам интерфейс взаимодействия с плагинами (уже вторую неделю изучаю свою проблему).
И якопаю в сторону что должна быть определенная (в программе определнная) функция, которая читала бы данные из плагина. Я не могу точно написать словами (но короче хочу использовать def-файлы для видимости функций)
Цитата:
Originally posted by DissDoc
Я более менее продумал уже сам интерфейс взаимодействия с плагинами (уже вторую неделю изучаю свою проблему).
И якопаю в сторону что должна быть определенная (в программе определнная) функция, которая читала бы данные из плагина. Я не могу точно написать словами (но короче хочу использовать def-файлы для видимости функций)
Я более менее продумал уже сам интерфейс взаимодействия с плагинами (уже вторую неделю изучаю свою проблему).
И якопаю в сторону что должна быть определенная (в программе определнная) функция, которая читала бы данные из плагина. Я не могу точно написать словами (но короче хочу использовать def-файлы для видимости функций)
О def - это уж как удобней. А надо определиться не со списком функций, а с интерфейсом доступа к этим функциям. Тут не должно быть ничего особо сложного. Скажем, можно определить общую в плане присутствия функцию, и являющуюся по сути интерфейсом, вызывающим нужные методы, невидимые из главного модуля.
Что может быть проще - посмотреть, как реализуются плагины у того же фотошопа или винампа. Кстати, коренным образон переделать логику программы заменой плагина не удастся, т.к. плагин этот должен иметь строго определенный протокол взаимодействия с основным приложением. Отступ от этого протокола - смена и приложения и плагинов.
Катати, в этом смысле хорошо писать на Java - заменил пару класс-файлов в уже готовом приложении и все. А можно их вообще из сети подгружать и немедленно внедрять в работающий код, замещая старые загруженные вируальной машиной классы, не останавливая при этом всего приложения.
Это я к тому, что самый универсальное приложение с плагинами - это интерпретатор :D
Катати, в этом смысле хорошо писать на Java - заменил пару класс-файлов в уже готовом приложении и все. А можно их вообще из сети подгружать и немедленно внедрять в работающий код, замещая старые загруженные вируальной машиной классы, не останавливая при этом всего приложения.
Это я к тому, что самый универсальное приложение с плагинами - это интерпретатор :D
Цитата:
Originally posted by Archie
Что может быть проще - посмотреть, как реализуются плагины у того же фотошопа или винампа. Кстати, коренным образон переделать логику программы заменой плагина не удастся, т.к. плагин этот должен иметь строго определенный протокол взаимодействия с основным приложением. Отступ от этого протокола - смена и приложения и плагинов.
Катати, в этом смысле хорошо писать на Java - заменил пару класс-файлов в уже готовом приложении и все. А можно их вообще из сети подгружать и немедленно внедрять в работающий код, замещая старые загруженные вируальной машиной классы, не останавливая при этом всего приложения.
Это я к тому, что самый универсальное приложение с плагинами - это интерпретатор :D
Что может быть проще - посмотреть, как реализуются плагины у того же фотошопа или винампа. Кстати, коренным образон переделать логику программы заменой плагина не удастся, т.к. плагин этот должен иметь строго определенный протокол взаимодействия с основным приложением. Отступ от этого протокола - смена и приложения и плагинов.
Катати, в этом смысле хорошо писать на Java - заменил пару класс-файлов в уже готовом приложении и все. А можно их вообще из сети подгружать и немедленно внедрять в работающий код, замещая старые загруженные вируальной машиной классы, не останавливая при этом всего приложения.
Это я к тому, что самый универсальное приложение с плагинами - это интерпретатор :D
Вообще-то не так уж все это и определенно. А если этот протокол и будет одним из модулей? Или программа сама вся будет составлена из модулей? Строго определено что-то может быть между двумя непосредственно связанными по логике работы уровнями, а то, что идет через них, может вообще иметь другие принципы взаимодействия, если уж об этом говорить. Хотя это к делу отношения прямого не имеет, DissDoc, прошу прощения.
ArchieC интерпретатором я задумался )) Но боюсь в дебри уйти.. от сути боюсь уйти далеко
[QUOTE=DissDoc]ArchieC интерпретатором я задумался )) Но боюсь в дебри уйти.. от сути боюсь уйти далеко[/QUOTE]
Интерпретор - вещь, которая сама по себе стоит кандидатской диссертации, если ею плотно заниматься.
вычисление выражений, заданных в виде строки - вполне реальная задача.
А насчет плуг-инов - зачем они нужны? Ведь если в программу поместить то, что нужно пользователю и менять (дописывать) код, который есть - этого уже достаточно. Используй интерпретатор языка, на котором пишешь.
Интерпретор - вещь, которая сама по себе стоит кандидатской диссертации, если ею плотно заниматься.
вычисление выражений, заданных в виде строки - вполне реальная задача.
А насчет плуг-инов - зачем они нужны? Ведь если в программу поместить то, что нужно пользователю и менять (дописывать) код, который есть - этого уже достаточно. Используй интерпретатор языка, на котором пишешь.
Кошмар - то что вы тут про модули нагородили.
COM - не настолько эффективная модель чтобы использовать её для внутреннего взаимодействия.
Тебе подойдёт модель ядро<->модули. Реализуется это так:
Задаётся ядро, которое определяет:
Типы данных.
Способы обмена данными.
Способы обработки(фильтрации) данных.
Интерфесное взаимодействие(способы создания дочерних окон в фрейме, тулбаров, добавления/удаления пунктов меню, передача реакций на команды пользователя в модули)
Каскадное взаимодействие(совместная обработка модулями событий ядра, например drag&drop'а от одного модуля к другому).
Если эта инфраструктура у тебя есть - ты напишешь модули без особых проблем. Именно так реализован и фотошоп и винамп и много кто ещё...
COM - не настолько эффективная модель чтобы использовать её для внутреннего взаимодействия.
Тебе подойдёт модель ядро<->модули. Реализуется это так:
Задаётся ядро, которое определяет:
Типы данных.
Способы обмена данными.
Способы обработки(фильтрации) данных.
Интерфесное взаимодействие(способы создания дочерних окон в фрейме, тулбаров, добавления/удаления пунктов меню, передача реакций на команды пользователя в модули)
Каскадное взаимодействие(совместная обработка модулями событий ядра, например drag&drop'а от одного модуля к другому).
Если эта инфраструктура у тебя есть - ты напишешь модули без особых проблем. Именно так реализован и фотошоп и винамп и много кто ещё...
В общем, Ireul прав - во-первых, ком не такая быстрая штука (особенно если ком-сервер работает в отдельном процессе, тратится уйма времени на межпроцессные вызовы и в работу включаются всякие там службы удаленного вызова процедур... жуть...), во-вторых, зачем усложнять задачу и чем вам не нравится DLL? Нужно только с самого начала продумать интерфейс основного модуля с плагинами. Как у Микрософта есть(была) привычка при создании WinAPI в его функциях предусматривать "на всякий случай" (т. е. для использования в дальнейших версиях) дополнительные аргументы, а в хелпе писать, что этот параметр "зарезервирован и должен быть NULL" - в принципе можно поступить и так... Хотя это не очень красиво выглядит...
Можно еще посмотреть, как сделано в Миранде. Достаточно забавно - они чем-то виндовую службу сообщений сымитировали.
Еще можно взглянуть в соседнюю ветку, где говорится про решения от Borland. Правда, хер его знает, как это в Си-синтаксисе пишется. Но доступ к ним точно есть - Дельфи и Билдер - близнецы-братья.
Еще можно взглянуть в соседнюю ветку, где говорится про решения от Borland. Правда, хер его знает, как это в Си-синтаксисе пишется. Но доступ к ним точно есть - Дельфи и Билдер - близнецы-братья.
[QUOTE=Ireul]
COM - не настолько эффективная модель чтобы использовать её для внутреннего взаимодействия.
[/QUOTE]
глупость. COM наверно самая быстрая из компонентных технологий. на ней построена такая вещь как Direct3d - где произодительность чуть ли не вопрос жизни и смерти. и все быстро работает.
COM - не настолько эффективная модель чтобы использовать её для внутреннего взаимодействия.
[/QUOTE]
глупость. COM наверно самая быстрая из компонентных технологий. на ней построена такая вещь как Direct3d - где произодительность чуть ли не вопрос жизни и смерти. и все быстро работает.
и вообще столько бестолковых советов на такой простой вопрос, ответ на который вообщем то содержится в первом посте. DLL - это и есть динамически подключаемые модули. A = A. вещь равняется самой себе ( как сказал кто то из философов-объективистов ). твоя задача определить общий набор функций который будет реализить каждая конкретная DLL. Другой вариант - выделить этот набор функций в абстракатный класс. и реализить его в производных классах. таким образом когда юзер командует выбрать тот или иной плагин мы создаем соответсвующий производный класс и задаем его ( например в качестве текущего ). в конструкторе мы можем реализить загрузку соответсвующей DLL например. вообщем почитай про паттерны, в частности AbstractFactory.
[QUOTE=warchangel]глупость. COM наверно самая быстрая из компонентных технологий. на ней построена такая вещь как Direct3d - где произодительность чуть ли не вопрос жизни и смерти. и все быстро работает.[/QUOTE]
Это всего лишь компромис.
Это всего лишь компромис.
[QUOTE=Green]Это всего лишь компромис.[/QUOTE]
компромисс чего с чем ? я когда то помнил но забыл :) . как миниум это еще и результат желания MS иметь собственную библиотеку для работы с 3d, оснонованную не на OpenGL, а то сча умников всяких много возьмут да и запретят использование OpenGL в коммерческих ОС.
компромисс чего с чем ? я когда то помнил но забыл :) . как миниум это еще и результат желания MS иметь собственную библиотеку для работы с 3d, оснонованную не на OpenGL, а то сча умников всяких много возьмут да и запретят использование OpenGL в коммерческих ОС.
Компромис между быстродействием и универсальностью.