Создаю библиотеку для работы с последовательными портами. [УШЕЛ ИЗ ПРОЕКТА].

[pastor]

API данных класов я так понимаю одинаковое. Разместить объявление в одном общем *.h и разнести определение по *.cpp для каждой платформы: *_win.cpp, *_unix.cpp, *_mac.cpp, etc.

так оно и было (есть)

так зачем наследование и метод create()?


upd: Заглянул в исходники. Несовсем так. Имена классов для различных платформ не одинаковое.

[kuzulis]

так зачем наследование и метод create()?

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

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

Код

C++ (Qt)
SerialPort::SerialPort(QObject *parent)
    : QIODevice(parent)
    , d_ptr(new SerialPortPrivate(this))
{}
 

создавал бы базовый класс SerialPort, а не тот что реально нужен (SerialPort для винды - WinSerialPort).

upd: Заглянул в исходники. Несовсем так. Имена классов для различных платформ не одинаковое.

В смысле?

ЗЫ: и парни, разберитесь досконально в исходниках, перед тем как что-то советовать (это камень к пастору) .

[b-s-a]

pastor, имена разные для того, чтобы путаницы при отладке не было. Да и чтобы парсеры IDE сильно не насиловать.

[pastor]

ЗЫ: и парни, разберитесь досконально в исходниках, перед тем как что-то советовать (это камень к пастору) .

Совершенно необоснованный ничем камень в мою сторону. Я так понимаю b-s-a понял очем речь. При одинаковых именах отпадает надобность в методе create() и впринципе в наследовани. Но это всего другой подход к решению одной и тойже задачи.

ЗЫ: А исходники я конечно смотрел.

Вот короткая иллюстрация:

serialport_p.h

Код

C++ (Qt)
class SerialPortPrivate
{
public:
    // some common methods
...
#ifdef Q_WS_WIN
   //some windows specified methods
#endif
#ifdef Q_WS_MAC
   //some mac specified methods
#endif
#ifdef Q_WS_X11
  //some unix specified methods
#endif
.... 
private:
    // some common data
};

В  файле serialport.cpp будет находится общая для всех платформ реализация методов.
В фалах serialport_win.cpp, serialport_mac.cpp, serialport_unix.cpp будет находиться реализация этих методов для каждой платформы

Ну и наконец

Код

C++ (Qt)
SerialPort::SerialPort(QObject *parent)
    : QIODevice(parent)
    , d_ptr(new SerialPortPrivate(this))
{}

создавал бы все что нужно вне зависимости от платформы.

В качестве примера можно рассмотреть qthread класс.

ЗЫЫ: Чтобы не перегружать serialport_p.h специфическими для платформы вспомогательными методами, их можно вынести в соотвествующее cpp файлы и оформить как статические функции.

[pastor]

pastor, имена разные для того, чтобы путаницы при отладке не было. Да и чтобы парсеры IDE сильно не насиловать.

Путаницы и сложности отладки я ненаблюдал, но снова таки дело вкуса.

[kuzulis]

2 pastor,
да, я понял твою мысль.
Но, увы, там будут не только платформоспецифичные методы, но и переменные.
Поэтому всё усложнится и загромоздится, если все сваливать в один заголовочный файл.
Поэтому, лучше всё это разделить на несколько заголовков.

[b-s-a]

В принципе, можно все слить в cpp платформы... Но на мой взгляд это не очень практично.

[kuzulis]

Ну так как сделать то?
Я склоняюсь к варианту всё разделить (например, так сделаны Qt4 классы: евент диспетчер и т п.).

[b-s-a]

Мне разделенный вариант тоже нравится больше. Так как каши меньше - не люблю огромные исходники.

[kuzulis]

Блин, с разделением тоже не все гладко.
Проблема с методами:

Код

C++ (Qt)
bool SerialPortPrivate::canReadNotification()
{
#if defined (Q_OS_WINCE)
    QMutexLocker locker(&m_readNotificationMutex);
#endif
 
    Q_Q(SerialPort);
...
...
emit q->readyRead();
...
...
}
 
bool SerialPortPrivate::canWriteNotification()
{
#if defined (Q_OS_WINCE)
    QMutexLocker locker(&m_writeNotificationMutex);
#endif
...
...
}
 

т.е. если методы принадлежат классу SerialPortPrivate, то этот класс не видит
члены m_writeNotificationMutex, m_readNotificationMutex которые являются платформоспецифичными (для вин це)
и реально находятся в классе наследнике WinSerialPortPrivate.

если же эти методы перенести в WinSerialPortPrivate, то перестает работать макрос  Q_Q(SerialPort); ,
и выдает ошибку на emit q->readyRead();

Вот засада.  

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

ЗЫ: я приаттачил редактированную версию в которой проявляется проблема. (компилить пока на Linux)

[pastor]

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

Можно сделать в этом случае вот как:

Код

C++ (Qt)
class SerialPortPrivateData;
 
class SerialPortPrivate
{
public:
    // some common methods
...
private:
    // some common data
    SerialPortPrivateData *m_data;
};

В SerialPortPrivateData будут "сложены" все переменные класа и методы каждой платформы в отдельности.

И каждый платформенный cpp будет иметь свое объявление и реализацию SerialPortPrivateData.

В таком случае иы измежим нагромождение дефайнов с хэдере.

[kuzulis]

2 pastor,
ну так это уже получается что m_data имеет тот же эквивалент, что и engine в исходниках Qt4 для сокетов и пр. классов. Не?
А если это так - то мы же (b-s-a) был против такого деления (хотя я был не против ).
Т.е. через engine бла сделана версия библиотеки 0.4.0 и master ветка.

[pastor]

Ну я бы неназвал это engine. Скорее это приватные данные приватного класса ))

[kuzulis]

Ну я бы неназвал это engine. Скорее это приватные данные приватного класса ))

Кинь, если не затруднит, твой примерчик с приватными данными, применительно к реальной реализации.,
т.е. с набором тех методов и членов, которые ты бы сунул в эти приватные данные.

[pastor]

Кинь, если не затруднит, твой примерчик с приватными данными, применительно к реальной реализации.,
т.е. с набором тех методов и членов, которые ты бы сунул в эти приватные данные.

Ок