Архитектура ..

[Old]

Хмм.. ну вот допустим предлагается класс SortOp. Да, вроде задача на него возложена четко - сортировать. Но как он будет сортировать по частоте? Откуда он возьмет хеш/мап частот? Построит сам?

Попробуем на пальцах. Ему передается объект StatData, вот в нем и будет хеш. Этот хеш будет строиться парсером при разбиение исходного текста.

И кто будет строить цепочки из 3 process?

Ээээ. пользовательский код.

Логичнее при изменениях в UI сразу заряжать опции и, возможно, вызывать один propcess/go.

А так и есть. Вы просто не понимаете как это работает.

А так где хранить экземпляры этих многочисленных классов?

На Луне?

Однако мы как бы все дальше и дальше уходим в "мир грез". Задачка-то детская, а мы уже нагородили 3 класса, и вроде как это только начало 

Да нет, это для вас она десткая, а у Spark должно быть много сложной работы.

Бросаясь немедленно в boost::regex Вы вероятно избегнете многих велосипедов, но в то же время и "попадете под влияние". Какую структуру данных выберете для слова? Ну конечно же бустовскую, вряд ли вообще задумаетесь над какой-то сущностью. А поскольку "слово" проходит везде - все будет завязано на итератор дуста.

Бред. Жаль что вы не читаете/не понимаете сообщения других участников обсуждения.

Логичнее было ее локализовать - а там уж применить столь любимый Вами буст.

Так вот это и делается.

Процитирую вас же:

Выполняйте, и для typeOffset тоже. Свое мнение будете высказывать когда освоите что говорят 

[Bepec]

Ребят, а мб вы поспорите о разработке, проблемах и ошибках при разработке модульных приложений? По этой теме я б послушал дебаты

[Old]

Споры и дебаты не интересны, а вот обсудить и что-то придумать можно.
У вас есть вопрос/проблема - вбрасывайте.

[Bepec]

Да задумался я тут о своих прикладных программах - аля анализаторы/парсеры и прочая фигня. Их довольно много - штук 20. Вот и восхотелось собрать их "в одно". Чтобы можно было добавлять / удалять новые и что бы не было проблемы аля "где лежит что-то там". Как это получше сделать?

[Old]

Да задумался я тут о своих прикладных программах - аля анализаторы/парсеры и прочая фигня. Их довольно много - штук 20. Вот и восхотелось собрать их "в одно". Чтобы можно было добавлять / удалять новые и что бы не было проблемы аля "где лежит что-то там". Как это получше сделать?

Вы хотите переделать их в плагины и использовать их в одной оболочки? Или просто запускать разные программы из одной оболочки?

[Bepec]

Вот и думаю как лучше сделать и реально ли это Плагинами хотелось. "

[Old]

Вот и думаю как лучше сделать и реально ли это Плагинами хотелось. "

Для такой архитектуры очень важно качественно продумать интерфейсы.
Как и что анализаторы/парсеры анализируют (что является входными данными) и что получается на выходе (выходные данные)?

[Bepec]

В принципе на входе у них у всех массив строк - пакеты данных. Их основная задача разбор их по протоколам, анализ, вывод графиков и зависимостей.

update: Ну и часть цепляется к базе данных для более масштабного анализа, или же к файлам лога.

[Igors]

Попробуем на пальцах. Ему передается объект StatData, вот в нем и будет хеш. Этот хеш будет строиться парсером при разбиение исходного текста.

А чего это парсеру считать частоту - его дело побить на слова. Вообще впечатление что Вы просто нахрюкали классов на каждый чих, нисколько не заботясь о их взаимодействии/зависимостях. Как клиенту пользоваться задуманными классами - не знаете, где хранить их экземпляоы - тоже. В каком формате "слово" - тоже пока ничего нет. Зато классов уже много 

Вы просто не понимаете как это работает.

Здесь и дальше - просто дешевые понты - игнорирую

[Old]

Вообще впечатление что Вы просто нахрюкали классов на каждый чих, нисколько не заботясь о их взаимодействии/зависимостях. Как клиенту пользоваться задуманными классами - не знаете, где хранить их экземпляоы - тоже. В каком формате "слово" - тоже пока ничего нет. Зато классов уже много  

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

[Old]

В принципе на входе у них у всех массив строк - пакеты данных. Их основная задача разбор их по протоколам, анализ, вывод графиков и зависимостей.
 
update: Ну и часть цепляется к базе данных для более масштабного анализа, или же к файлам лога.

Давайте начнем с ядра и прикинем, какие возможности оно должно предоставлять модулям.
Ядро - это программа которая загружает и регистрирует модули. Она предоставляет главное окно, в котором модули с помощью специального api могут размещать свои окна, панель главного меню и панели инструментов (доступ к ним так же возможен через специальные api).
Ядро загружает модули и инициализирует их, передавая каждому модулю ссылку на рабочее пространство (workspace). Рабочее пространство это объект, который объединяет в себе все рычаги управления. Так мы избавимся от 100500 синглетонов, которые частенько очень не удачно используют как точки доступа к некоторым объектам из любого места.
Рабочее пространство должно быть расширяемым: любой модуль может добавить указатель на себя, что бы другие модули могли использовать его функционал.
Теперь нужно продумать все api:
* управление окнами
* управление меню
* управление панелями инструментов
Предлагаю продумать их вместе.

[Old]

Набросал проект. На нем можно будет упражняться.
Привожу функцию main с комментариями, там показан текущий функциона. Загружается и регистрируется внешний сервис логер и в main он достается и используется.

Код

C++ (Qt)
int main( int argc, char *argv[] )
{
        QApplication app( argc, argv );
 
        // Создаем рабочее пространство
        Workspace ws;
 
        // Загружаем модули
        // При загрузке модули могут регистрировать в рабочем пространстве свои сервисы
        PluginManager pluginmanager;
        pluginmanager.loadPlugins( ws );
 
        // Выводим список сервисов
        ws.dump();
 
        // Получаем указатель на логгер по его интерфейсу
        ILogger *l = ws.service<ILogger>();
        Q_ASSERT( l );
        // Используем сервис логирования
        l->log( "Test string" );
 
        return 0;       // app.exec();
}
 

[Bepec]

Смотрю.

[Old]

Ядро - это программа.... Она предоставляет главное окно..., панель главного меню и панели инструментов...

Я вот сейчас подумал. А почему ядро должно предоставлять GUI? Пусть его предоставляет один из модулей.
Он создаст главное окно и будет обеспечивать весь api связанный с GUI.
Верес, какой вы видите GUI для ваших анализаторов? MDI/SDI? Наличие главного меню/панелей инструментов?

[Igors]

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

Код

C++ (Qt)
int Main( int command, size_t dataSize, void * data );

Дальше просто рисуете N структур которые подаете как data. А оте все "турусы на колесах" работать не будут