Надо написать кросплатформенную GUI либу. Почитав банду "четырех", понял, что нужно использовать абстр. фабрику и мост. Как реализовать эту кроссплатформенность. Так кросплатформенность на уровне библиотеки, то надо написать два разных кода под разные системы? Или как?
Быдло бы замечательно если бы дали пример.

N>Надо написать кросплатформенную GUI либу. Почитав банду "четырех", понял, что нужно использовать абстр. фабрику и мост. Как реализовать эту >кроссплатформенность. Так кросплатформенность на уровне библиотеки, то надо написать два разных кода под разные системы? Или как?
N>Быдло бы замечательно если бы дали пример.

http://www.thefreecountry.com/sourcecode/gui.shtml

Здравствуйте, na1s, Вы писали:

N>Надо написать кросплатформенную GUI либу. Почитав банду "четырех", понял, что нужно использовать абстр. фабрику и мост. Как реализовать эту кроссплатформенность. Так кросплатформенность на уровне библиотеки, то надо написать два разных кода под разные системы? Или как?
N>Быдло бы замечательно если бы дали пример.

пример

Есть абстрактная фабрика, как она знает какой объек создавать?

Здравствуйте, na1s, Вы писали:

N>Есть абстрактная фабрика, как она знает какой объек создавать?
она не знает. абстрактная фабрика это интерфейс через который запрашивают экземпляры. реализация (конкретная) фабрика реализующая интерфейс данной абстрактной фабрики знает. Смысл этого паттерна в том чтобы разделить место получения и создания (и соотв зависимость от знания как и какие объекты создавать).

Здравствуйте, na1s, Вы писали:

N>Надо написать кросплатформенную GUI либу. Почитав банду "четырех", понял, что нужно использовать абстр. фабрику и мост. Как реализовать эту кроссплатформенность. Так кросплатформенность на уровне библиотеки, то надо написать два разных кода под разные системы? Или как?
N>Быдло бы замечательно если бы дали пример.

Фабрика тут ни при чем.

void Window::addButton(params)
{
#if defined(__DOORS32__)
    CreateButton(m_hwnd, params);
#elif defined(__Y11__)
    add_button(params, m_handle, 42);
#elif . . .
    . . .
#endif
}

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, na1s, Вы писали:

N>>Надо написать кросплатформенную GUI либу. Почитав банду "четырех", понял, что нужно использовать абстр. фабрику и мост. Как реализовать эту кроссплатформенность. Так кросплатформенность на уровне библиотеки, то надо написать два разных кода под разные системы? Или как?
N>>Быдло бы замечательно если бы дали пример.

RO>Фабрика тут ни при чем.
RO>

RO>void Window::addButton(params)
RO>{
RO>#if defined(__DOORS32__)
RO>    CreateButton(m_hwnd, params);
RO>#elif defined(__Y11__)
RO>    add_button(params, m_handle, 42);
RO>#elif . . .
RO>    . . .
RO>#endif
RO>}
RO>

Так используя препроцессор как-то не красиво, может быть существует более изящное решение?

Здравствуйте, dotidot, Вы писали:

D>Здравствуйте, na1s, Вы писали:

N>>Есть абстрактная фабрика, как она знает какой объек создавать?
D>она не знает. абстрактная фабрика это интерфейс через который запрашивают экземпляры. реализация (конкретная) фабрика реализующая интерфейс данной абстрактной фабрики знает. Смысл этого паттерна в том чтобы разделить место получения и создания (и соотв зависимость от знания как и какие объекты создавать).
Тогда используя интерфейс, я могу получить экземпляр соотсветсвующего объекта, т.е у меня будут 2 разные версии кода под разные системы?
В одной используя WINAPI, в другой Xlib.

Здравствуйте, na1s, Вы писали:

N>Так используя препроцессор как-то не красиво, может быть существует более изящное решение?

Какое такое изящное решение? Тебе всё равно на разных платформах придется включать разные заголовочные файлы и вызывать разные функции, как без препроцессора?

Ты, похоже, хочешь в рантайме определять платформу и обращаться к соответствующему API. Но я сомневаюсь, что в процессе выполнения программы вдруг сотрется Linux и установится Windows (полтергейтс).

Если можно выполнить проверку во время компиляции, то так и нужно поступить.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, na1s, Вы писали:

N>>Так используя препроцессор как-то не красиво, может быть существует более изящное решение?

RO>Какое такое изящное решение? Тебе всё равно на разных платформах придется включать разные заголовочные файлы и вызывать разные функции, как без препроцессора?

RO>Ты, похоже, хочешь в рантайме определять платформу и обращаться к соответствующему API. Но я сомневаюсь, что в процессе выполнения программы вдруг сотрется Linux и установится Windows (полтергейтс).

RO>Если можно выполнить проверку во время компиляции, то так и нужно поступить.
Тогда мне лучше делать 2 библиотеки с разным кодом, или 1 библиотека с ifdefami?

Здравствуйте, na1s, Вы писали:

N>Тогда мне лучше делать 2 библиотеки с разным кодом, или 1 библиотека с ifdefami?
Лучше всего продумать архитектуру.

Я так понимаю, что ты хочешь написать какую-то dll с пользовательстким интерфейсом. Или библиотеку для развития интернфейсов?

ИМХО тут важно учесть два аспекта.
С одной стороны в пользовательском интерфейсе есть некая внутреннья логика, в принципе не связанная с платформой. Ну, напрмиер, в редакторе текста надо обеспечит оттображение курсора, текста вокруг курсора, аттрибутов текста, кнопочек там всяких и контекстных меню, для ввода команд, горячих клавиш для воода команд и навигации и т. д.

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

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

Так вот, ИМХО очень важно проработать архитектуру пользовательского интерфейса в том смысле, что сформулировать слой, абстрагированный от платформы. То есть в терминах внутренней логики программы и слой специфичный для платформы, которые вырабатывает команжы для первого и отображает его реакции.

Ну а дальше формализуешь интерфейс между слоями и один пишешь фулпортабл, а второй реализуешь на каждой платформе так, как это там принято (например используя принятые там библиотеки, контролы, прнцыпы организации пользоватльского интерфейса и т. д.)

N>Тогда используя интерфейс, я могу получить экземпляр соотсветсвующего объекта, т.е у меня будут 2 разные версии кода под разные системы?
N>В одной используя WINAPI, в другой Xlib.
две разные версии кода GUI библиотеки. Код же GUI апликухи юзающий библиотеку меняться н будет.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, na1s, Вы писали:

N>>Тогда мне лучше делать 2 библиотеки с разным кодом, или 1 библиотека с ifdefami?
E>Лучше всего продумать архитектуру.

E>Я так понимаю, что ты хочешь написать какую-то dll с пользовательстким интерфейсом. Или библиотеку для развития интернфейсов?

E>ИМХО тут важно учесть два аспекта.
E>С одной стороны в пользовательском интерфейсе есть некая внутреннья логика, в принципе не связанная с платформой. Ну, напрмиер, в редакторе текста надо обеспечит оттображение курсора, текста вокруг курсора, аттрибутов текста, кнопочек там всяких и контекстных меню, для ввода команд, горячих клавиш для воода команд и навигации и т. д.

E>При этом что происходит при поступлении команды "перейти к след. абзацу" -- это логика, которая от платформы не зависит, а вот то, как именно вводится пользователем эта команда зависит.

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

E>Так вот, ИМХО очень важно проработать архитектуру пользовательского интерфейса в том смысле, что сформулировать слой, абстрагированный от платформы. То есть в терминах внутренней логики программы и слой специфичный для платформы, которые вырабатывает команжы для первого и отображает его реакции.

E>Ну а дальше формализуешь интерфейс между слоями и один пишешь фулпортабл, а второй реализуешь на каждой платформе так, как это там принято (например используя принятые там библиотеки, контролы, прнцыпы организации пользоватльского интерфейса и т. д.)
Архитектуру как раз и продумываю, для этого прочитал Гамму, там написано для отделения абстракции от ее реализации, необходимо использовать мост и абстрактную фабрику. Мост я более-менее понял, проблема как реализовывать фабрику?

Здравствуйте, na1s, Вы писали:

N>Архитектуру как раз и продумываю, для этого прочитал Гамму, там написано для отделения абстракции от ее реализации, необходимо использовать мост и абстрактную фабрику. Мост я более-менее понял, проблема как реализовывать фабрику?

При чём тут фабрика? Это вообще не о том всё

N>>Архитектуру как раз и продумываю, для этого прочитал Гамму, там написано для отделения абстракции от ее реализации, необходимо использовать мост и абстрактную фабрику. Мост я более-менее понял, проблема как реализовывать фабрику?

E>При чём тут фабрика? Это вообще не о том всё

Да не, о том. Точнее, так думают те, кто написал эту книгу. Там абстрактная фабрика используется для платформенно-независимой реализации элементов GUI. Типа такого (там все несколько сложнее, на самом деле, но вырожденный случай именно такой):

struct AbstractGUIFactory
{
   virtual Window *CreateWindow(...) = 0;
   virtual Button *CreateButton(...) = 0;
   etc
};

struct ConcreteX11GUIFactory
{
   virtual Window *CreateWindow(...) = 0;
   virtual Button *CreateButton(...) = 0;
   etc
};

struct ConcreteWin32GUIFactory
{
   virtual Window *CreateWindow(...) = 0;
   virtual Button *CreateButton(...) = 0;
   etc
};

AbstractGUIFactory *GetGUIManager()
{
...
}

Но вот о том, каким образом это дело вообще работать будет (то бишь, каким образом слинкуется и запустится, да и нафига в программе на конкретной платформе никогда не используемый там код) там никто не думает... Одно дело, когда это все применяется только к поведению и внешнему виду элементнов GUI (и то, для меня совсем странно, когда элемент GUI ведет себя не так или не так выглядит, как его системная реализация), и совсем другое — конкретной реализации на уровне системных вызовов. К сожалению, много чего в этом труде оторвано от реальностей, надо читать с бооольшой осторожностью, и лучше не первой книгой — примеры применения неплохих, в общем то, паттернов там бывают просто ужасные.

К автору топика:
А вам лучше использовать уже существующие решения, или, если очень тянет заняться велосипедным спортом, определить основные элементы управления, их поведение и параметры, определить достаточный и необходимый интерфейс (не только самих элементов, но и их реализации — то, что в книге обозвано с постфиксом Impl, суть системно-зависимый интерфейс) и реализовать — часть препроцессором, часть в виде отдельно статически линкуемых библиотек, и настройку платформы производить именно препроцессором. Т.е. не XxxWindowImpl, как рекомендовано там, а одна и только одна WindowImpl, которая определяется препроцессором (можно, и наверное, даже лучше, если функциональность этих Impl не пересекается, ведь они для того и сделаны, нарожать несколько Impl, а затем препроцессором определить нужные типдефы, именно так и было в какой то кроссплатформенной библиотеке).

Здравствуйте, Andrew S, Вы писали:

AS>ведь они для того и сделаны, нарожать несколько Impl, а затем препроцессором определить нужные типдефы, именно так и было в какой то кроссплатформенной библиотеке).

Можно просто сделать несколько альтернативных CPP и включать на нужной платформе нужный.
Кроме всегопрочего на разных платформах ещё и разные кодировки исходников, концы строк, предкомпилированные хедеры, прагмы и т. д...

Здравствуйте, Erop, Вы писали:

E>Можно просто сделать несколько альтернативных CPP и включать на нужной платформе нужный.
E>Кроме всегопрочего на разных платформах ещё и разные кодировки исходников, концы строк, предкомпилированные хедеры, прагмы и т. д...

Да, кстати, этот подход легко сочетается с абстрактной фабрикой, только, ИМХО это не обязательно таки называть так громко.

Пишешь что-то типа:

// MyGuiSubsystem.h
// Это единственный абсолютно переносимый хедер

struct IMyGuiSubsystem {
    virtual  void Method1() = 0; 
    // И так далее

    static IMyGuiSubsystem* Get();
};

И теперь пишешь реализацию:

// MyGuiSubsystem4Winows.h
#include <MyGuiSubsystem.h>

class CMyGuiSubsystem4Winows : public IMyGuiSubsystem {
    // Тут собственно код, включая все поддробности реализации, который может свободно 
    //  использовать реалии WIN 32 API
};

и

// MyGuiSubsystem4Winows.cpp
#include "MyGuiSubsystem4Winows.h@"

static CMyGuiSubsystem4Winows theMyGuiSubsystem4Winows;
IMyGuiSubsystem* IMyGuiSubsystem::Get() { return theMyGuiSubsystem4Winows; }
//-------------------------
// Тут реализация CMyGuiSubsystem4Winows

При этом, есл реализация менеджера нуждается в каких-то кроссплатформенных кусках (например в контейнерах), то она снова может использовать кроссплатформенный слой. Так что получится два слоя, один -- общий для всех платформ, а второй -- специфичный для каждой.

E>>Можно просто сделать несколько альтернативных CPP и включать на нужной платформе нужный.
E>>Кроме всегопрочего на разных платформах ещё и разные кодировки исходников, концы строк, предкомпилированные хедеры, прагмы и т. д...

E>Да, кстати, этот подход легко сочетается с абстрактной фабрикой, только, ИМХО это не обязательно таки называть так громко.

Зачем тут абстрактная фабрика, если ее реализация (то бишь тип продукта) таки будет только одна? Имхо, никаких абстрактностей тут не нужно — на уровнях взаимодействия с системой (и соответственно, уровнем выше) все будет вполне конкретно, без вариантов. Либо с вариантами, настраиваемыми при компиляции — т.е. компилей тайм стратегии, как в той же WTL.

RO>>Если можно выполнить проверку во время компиляции, то так и нужно поступить.
N>Тогда мне лучше делать 2 библиотеки с разным кодом, или 1 библиотека с ifdefami?

без ifdefoв все равно не обойтись.
возможен такой вариант:
разделить библиотеку на интерфейс и имплементацию.
интерфейс — это общие исходники которые компилятся для всех платформ.
имплементация — исходники специфичные для платформы, они подключаются с помощью макрософ компиляции.
в принципе, можно выделить и какую-то общую часть имплементации как дополнительный слой абстракции,
и сделать ее компилябельной на всех поддерживаемых платформах

E>>Можно просто сделать несколько альтернативных CPP и включать на нужной платформе нужный.
E>>Кроме всегопрочего на разных платформах ещё и разные кодировки исходников, концы строк, предкомпилированные хедеры, прагмы и т. д...

E>Да, кстати, этот подход легко сочетается с абстрактной фабрикой, только, ИМХО это не обязательно таки называть так громко.

AF к гуевым библиотекам можно применить для реализации динамического создания объектов в рамках ОДНОЙ платформы.

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