Не, я сделаю как планировал ранее. ИМХО, так красивше.

А зачем? В сокетах тоже нет мьютекса.

Ок, оставлю только у действительно "нативных" методов.

Ошибся.

ok

Зачем нужен метод void AbstractSerialPortPrivate::initVariables()? Чем конструктор не подходит?
Предлагаю вместо этого:

C++ (Qt)
virtual bool setRate(qint32 rate, SerialPort::Directions dir) = 0;
virtual qint32 rate(SerialPort::Directions dir) const = 0;

Для минимизации потенциального дублирования кода, использовать это (AbstractSerialPortPrivate):

C++ (Qt)
bool setRate(qint32 rate, SerialPort::Directions dir) {
   if (setNativeRate(rate, dir)) {
      mRate = rate;
      return true;
   }
   return false;
}
qint32 rate(SerialPort::Directions dir) const {
   if (dir & Input)
      return (dir & Output) ? ((mInRate + mOutRate)/2) : mInRate;
   return mOutRate;
}
//...
protected:
virtual bool setNativeRate(int rate, SerialPort::Directions dir) = 0;

Аналогично с остальными методами (т.е. чтобы не писать в каждой реализации "mParity = parity" и т.п.).

C++ (Qt)
 virtual bool saveOldsettings() = 0;
 virtual bool restoreOldsettings() = 0;

Действительно ли это нужно? Или все-таки можно использовать стандартные механизмы?

А вот это:

C++ (Qt)
    virtual void detectDefaultRate() = 0;
    virtual void detectDefaultDataBits() = 0;
    virtual void detectDefaultParity() = 0;
    virtual void detectDefaultStopBits() = 0;
    virtual void detectDefaultFlowControl() = 0;
 
    void detectDefaultSettings()
    {
        detectDefaultRate();
        detectDefaultDataBits();
        detectDefaultParity();
        detectDefaultStopBits();
        detectDefaultFlowControl();
    }

я предлагаю упростить до:

C++ (Qt)
virtual void detectDefaultSettings() {}

Так как реализовывать 5 виртуальных функций, которые вызываются только в одном месте я не вижу никакого смысла.

Кстати, названия полей класса будем приводить к стандартному в Qt виду (m_xxxx)?

Файл qserialdevice_global.h имхо не очень нужен, тем более, что он (по идее) должен использоваться в публичных хидерах (а еще у него лицензия GPL). Для начала предлагаю просто ограничиться в каждом публичном хидере:

C++ (Qt)
#ifdef SERIALPORT_SHARED
# ifdef SERIALPORT_BUILD
#  define SERIALPORT_EXPORT Q_DECL_EXPORT
# else
#  define SERIALPORT_EXPORT Q_DECL_IMPORT
# endif
#else
# define SERIALPORT_EXPORT
#endif

Ты так и не сделал разделение serialport_p.h на serialport_p_win.h и serialport_p_unix.h. А стоило бы - на данный момент наличие AbstractSerialPortPrivate смысла не имеет.

Сделал ряд исправлений. см. аттачмент.

А как мне склонировать ветку 2.0? А то клонирую мастера постоянно.

b-s-a
Спасибо, вроде разобрался и залил твою версию.

у меня на работе админом закрыты все порты кроме 8080 и т.п.. , т.е. я не могу оттуда сразу вносить изменения.
Поэтому я аттачу на форум, а потом, из дома уже коммиты вношу.

Ок.

Подходит. Просто писанины в конструкторе прибавится.

Ок. Только нужно наверное немного изменить твою реализацию методов setRate() / rate().

Ну, вот, с методами setPort() / port() так просто не получится. Т.е. твою реализацию нужно подправить.
Что имею ввиду:
переменная mPort должна по идее всегда хранить длинные имена портов,
нативный метод setPort() (к примеру, для винды) должен из короткого имени "COM1" делать длинное "\\\\.\\COM1", а если на входе длинное имя - то ничего не делать.
И далее, это длинное имя он присваивает переменной mPort. (В линуксе и пр. ОС аналогично).
Метод же port() должен из длинного имени делать короткое и возвращать результат (мы ж так условились).

Поэтому можно было бы добавить еще методы nativeSetPort() / nativePort(). Т.е. для каждой из платформ будет своя реализация (на QRegExp к примеру).
Но если оставить так как есть сейчас - то придется химичить с дефайнами в serialport_p.h, что не есть хорошо, т.к. для этого есть serialport_p_unix/win.h
ИМХО.

Что имеешь ввиду под стандартными механизмами?
Сохранять/восстанавливать предыдущие параметры то нужно по-любому (после открытия и перед закрытием).

Насчет упростить и оставить virtual void detectDefaultSettings() {} :
ну, тут если упрощать - то слишком много кода придется писать в этот метод,
т.е. будет громоздко. ИМХО, лучше его разбить на 5 стадий по смыслу.

Насчет префиксов m/m_ у приватных членов - то может быть, их вообще не писать (т.е. опускать их)?
т.к. я бегло просмотрел исходники Qt и там очень редко встречается этот префикс.
Хотя, в исходниках QtCreator - повсеместно.
А то лишняя писанина получается и имя переменной растет.

----
А в целом, просмотрев твои идеи, согласен, давай так.

ок, думаю по ходу процесса, думаю, мне станет яснее.

b-s-a,

Я пока заккомитил свою версию.

После этого увидел, что и ты мерж новый подогнал.

Вопросы:
1. Почему ты сменил каталог src на lib?
2. Зачем ты в serialport.cpp/serialportinfo.cpp
добавил дефайны и подключаешь приватные заголовки?

C++ (Qt)
#ifdef Q_OS_WINDOWS
# include "serialport_p_win.h"
#elif defined(Q_OS_UNIX)
# include "serialport_p_unix.h"
#else
# error Unsupported Operating System
#endif
 

Имхо, это не правильно. Реализация в serialport.cpp ничего не должна знать об платформо зависимых вещах.
3. Почему убрал *.pri файл?

Тьфу, заработался. Там еще много косяков.
Повелся не думая за b-s-a

2 b-s-a,
просмотрел еще раз твой мерж, и не понял: а чем тебя не устроил мой первоначальный вариант с AbstractPortPrivate ?
Тем более, что в твоей реализации нужно дополнительно создавать два лишних файла serialport_p_win/unix.h (зачем???), в которых нужно дублировать методы и т.п.
Я то думал, это какой-то особый "финт", но преимуществ такого разделения так и не увидел., только лишние телодвижения, ИМХО.
Я склоняюсь больше к варианту аналогичному как в сокетах.

pastor ,
да и я тоже к такому.