LINUX.ORG.RU
Форум — Talks  

Какой способ использования фреймворков удобнее?

 ,


0

2

Вариант I: 

#include <libframe.h>
Один большой файл библитеки, все модули имеют доступ к данным друг друга, добавление нового модуля - рекомпиляция всей либы/фреймворка.
Пример: Gtk 
# include <gtk/gtk.h>

Вариант II: 

#include <libframe.h>
#include <libframe-window.h>
#include <libframe-button.h>
#include <libframe-sharedmemory.h>
Один core-файл и много мелких суббиблиотек, реализующих различные модули. Рекомпиляция нужного модуля не тянет рекомпиляцию всего проекта, после добавления нового модуля максимум что нужно сделать - это перезапустить приложения что его уже используют.
Пример: Qt 
#include <QAction>
#include <QtEvents>
#include <QFrame>
#include <QMainWindow>
#include <QMenu>
#include <QPainter>
#include <QImage>
#include <QColor>

Пожалуйста, помогите выбрать наиболее подходящий вариант для своего проекта (содержит работу с окнами, таймерами, шаренной памятью, виджетами и пр.). Какие плюсы и минусы у каждого варианта? Сабж

у нас делают так:

#include <libframe/window.h>
#include <libframe/button.h>
#include <libframe/sharedmemory.h>


иногда укрупняя несколько хедеров в модули типа #include <libframe/ui.h>

ps. почему в talks?

dib2 ★★★★★
()
Последнее исправление: dib2 (всего исправлений: 1)
Ответ на: комментарий от dib2

ps. почему в talks?

Потому что в development'e злые дяди модераторы сказали бы что тут нет вопроса на разработке и перенесли бы куда-нибудь подальше.

someoneelsenotme ★
() автор топика

Последний

P.S.: кутешнег

UVV ★★★★★
()

Правильный фреймворк умеет как

#include <libframe/window.h>
#include <libframe/button.h>
#include <libframe/sharedmemory.h>

для тех кому важна скорость компиляции, так и

#include <libframe.h>

для тех кому лень думать. Понятно что libframe.h должен просто включать все libframe/*.h.

slovazap ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Talks