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

[lit-uriy]

По поводу скоростей:
я бы взял список из QextSerialPort, там для разных ОСек разные наборы, т.е. естественные для каждого окружения.

[pastor]

Согласен, нужно одного стиля придерживатся. а метод line() вообще не понятен.

+1

[lit-uriy]

kuzulis, поздравляю!
Твоя библиотека стала активно обсуждатся. А это значит - пользователям захотелось стандартов.

[b-s-a]

В случае с setup, при изменение, допустим, DataErrorPolicy, нужно будет перечислить все значение до него, что не есть, имхо, удобно.

Вообще-то, я предполагал использование setup только в начале работы с портом - задать все настройки одним махом. Естественно, что настройку по отдельности никто отменять не будет.

[pastor]

Вообще-то, я предполагал использование setup только в начале работы с портом - задать все настройки одним махом. Естественно, что настройку по отдельности никто отменять не будет.

т.е. вызов setup опционален?

[lit-uriy]

на мой взгляд методы типа setup() должны быть приватными.
Да и вообще лучше придерживатся идеи самих тролей.

А насчёт метода open() и его аргумента OpenMode я что-то пропустил в обсуждении, просветите пожалуйста.
Какие могут быть режимы открытия COM Port-а?

[kuzulis]

Итак, парни, мои 5 копеек :
1. Все-же хотелось бы не менять название библиотеки, т.к. оно уже устоявшийся брэнд 
Тем более, проект с именем QSerialPort уже есть на гиториусе, а плодить кучу форков как-то не айс..
Согласны?
Я так понимаю, что если вдруг (с перепугу) проект вольется в состав Qt - то там без проблем можно будет изменить названия классов.

2.

Код

C++ (Qt)
bool flush(Directions dir = Input | Output);
 

ИМХО, тут не нужны никакие Input/Output т.к. flush работает только для передачи

Код

C++ (Qt)
    bool setBreak(bool set = true);
    bool clearBreak(bool clear = true);
 

Тут можно либо оставить только setBreak(bool) с входным параметром либо истина/либо ложь.
Или сделать два метода setBreak()/clearBreak() но вообще без входных параметров.

И все-таки, названия в перечислениях типа: NoParity, NoFlowControl как-то режут глаз, ИМХО.

3.

2) Переместить в приват или удалить вовсе метод setup. имхо это избыточно.

Я вообще не вижу в этом методе смысла. Зачем при открытии порта устанавливать какие-то умолчательные параметры?
Ведь на данный момент реализовано всё гораздо лучше чем эта идея!
Кстати, я отказался от установки умолчательных параметров уже давно, т.к. было очень много отзывов убрать эту возможность.
Вот зачем, спрашивается, устанавливать 9600,8,N,1 (к примеру) при открытии порта? (насмотрелись в QextSerialPort ? )
Лучше вообще, его просто открыть, и определить его текущие настройки, а потом, по желанию, установить то что нужно уже паблик методами.
Т.е. ИМХО, лучше оставить идею такой как она есть сейчас.
(или я что-то недопонял в методе setup() ?)

Блин, глянули бы в текущие исходники QSerialDevice бы, и всё стало бы ясно.

По поводу скоростей:
я бы взял список из QextSerialPort, там для разных ОСек разные наборы, т.е. естественные для каждого окружения.

А я бы не брал, т.к. в линухе они стандартны вплоть до 4Мбод, в маке нет, а в винде вообще можно любые ставить.
Еще я бы тогда убрал наверное вообше перечисление скоростей, а вместо этого всунул бы метод типа standartBauds() который бы возвращал
список скоростей для данной ОС.
Хотя, хз...

Согласен, нужно одного стиля придерживатся. а метод line() вообще не понятен.

Ты имеешь ввиду не понятно имя метода и что он делает, или предлагаешь
сделать кучу методов типа: le(), cts(), dcd() ??
Если первое - то поменять имя не проблема, если второе - то придется туеву хучу раз вызывать одну и туже системную функцию
для определения статуса каждой линии.
Стиль стилем, но надо ж искать золотую середину.

[kuzulis]

на мой взгляд методы типа setup() должны быть приватными.
Да и вообще лучше придерживатся идеи самих тролей.

О, по моему этот перевод сплагиатили скопипастили на хабр (что-то уж там точь в точь как тут).  .

И еще, почитав соглашения Qt стиля, покопавшись в исходниках Qt, пришел к выводу: а не лучше ли не сокращать так перечисления как мы сократили сейчас?

Т.е. , к примеру, вместо

Код:

    enum Parity {
        NoParity  = 0,     /*!< \~english No parity. */
        Even  = 2,         /*!< \~english Even parity. */
        Odd   = 3,         /*!< \~english Odd parity. */
        Space = 4,         /*!< \~english Space parity. */
        Mark  = 5,         /*!< \~english Mark parity. */
        UnknownParity = -1 /*!< \~english Parity unknown. */
    };

лучше написать:

Код:

    enum Parity {
        NoParity  = 0,     /*!< \~english No parity. */
        EvenParity  = 2,         /*!< \~english Even parity. */
        OddParity   = 3,         /*!< \~english Odd parity. */
        SpaceParity = 4,         /*!< \~english Space parity. */
        MarkParity  = 5,         /*!< \~english Mark parity. */
        UnknownParity = -1 /*!< \~english Parity unknown. */
    };

и т.п. и для остальных перечислений!
Т.е лучше конкретизировать смысл значения перечисления!

[lit-uriy]

>>Лучше вообще, его просто открыть, и определить его текущие настройки,
>>а потом, по желанию, установить то что нужно
а как можно открыть порт не задав режим его работы?

>>всунул бы метод типа standartBauds() который бы возвращал
>>список скоростей для данной ОС.
Да это полезно, можно без труда формочки клепать, если метод будет возвращать строки и будет метод который эти же строки скушает для установки скорости.

>>или предлагаешь сделать кучу методов типа: le(), cts(), dcd() ??
А что такое le()?

>>Т.е лучше конкретизировать смысл значения перечисления!
Я согласен. И лучше использовать пространство имён: QSerialDevice:: NoParity

[kuzulis]

>>а как можно открыть порт не задав режим его работы?
Элементарно:

Код

C++ (Qt)
// *nix
int fd = ::open(<имя>, <флаги>)
// windows
HANDLE h = ::CreateFile(<имя>, <флаги>);
 

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

>>Да это полезно, можно без труда формочки клепать, если метод будет возвращать строки и будет метод который эти же строки скушает для установки
Да, но тов. b-s-a против.

>>А что такое le()?
Line Enable

[lit-uriy]

>>то он будет работать от настроек по умолчанию
стало быть умалчиваемые настройки есть (не важно ОСьки или библиотеки).

>>Да, но тов. b-s-a против.
подкинь ссылку на обсуждение

>>Line Enable
И что же это такое? Про какую линию речь?

[kuzulis]

>>стало быть умалчиваемые настройки есть (не важно ОСьки или библиотеки).
Да, есть. Но при этом, метод setup() не нужен!  

>>подкинь ссылку на обсуждение
В этой теме чуть выше (на пару страниц), вот: http://www.prog.org.ru/index.php?topic=9537.msg123839#msg123839

>> И что же это такое? Про какую линию речь?
Line Enable
Я так понимаю, что это DSR,
но хз.
Просто в *nix есть константа: TIOCM_LE
и можно написать:

Код:

::ioctl(this->descriptor, TIOCMGET, &temp);
...
if (temp & TIOCM_LE) status |= AbstractSerial::LineLE; << Вот это
...
if (temp & TIOCM_DSR) status |= AbstractSerial::LineDSR; << А также есть это

[b-s-a]

ИМХО, тут не нужны никакие Input/Output т.к. flush работает только для передачи

Под линухом можно задать направление. Под Windows не помню.

Тут можно либо оставить только setBreak(bool) с входным параметром либо истина/либо ложь.
Или сделать два метода setBreak()/clearBreak() но вообще без входных параметров.

Тут смысл аналогичен методам setEnabled/setDisabled и setVisible/setHidden.

т.е. вызов setup опционален?

КОНЕЧНО!

Лучше вообще, его просто открыть, и определить его текущие настройки, а потом, по желанию, установить то что нужно уже паблик методами.
Т.е. ИМХО, лучше оставить идею такой как она есть сейчас.
(или я что-то недопонял в методе setup() ?)

Это просто удобный метод задать основные настройки и ничего более. А то, что он имеет кучу необязательных параметров - не проблема, можно, например, убрать policy. Тут смысл такой, что в подавляющем большинстве случаев порты работают в режиме без четности и с одним стопом, но практически всегда необходимо задать скорость. Если не использовать этот метод, то всегда при открытии порта надо будет ручками задавать следующие свойства:
1. скорость
2. четность
3. количество стопов
4. поведение при ошибке четности
При этом, с большой долей вероятности пользователь будет задавать 1 стоп и без четности (я уж не говорю про реакцию на ошибку четности, так как это вообще мало кому нужно). Так зачем его заставлять это делать каждый раз путем вызова 4-5 методов?

А насчёт метода open() и его аргумента OpenMode я что-то пропустил в обсуждении, просветите пожалуйста.
Какие могут быть режимы открытия COM Port-а?

В режиме только чтения, только записи, чтения и записи, с дополнительной буферизацией (это когда отправка/прием идут в отдельном потоке; оно надо вообще?) и без.

И все-таки, названия в перечислениях типа: NoParity, NoFlowControl как-то режут глаз, ИМХО.

Сам же потом будешь путаться с этими None и Off.

И еще, почитав соглашения Qt стиля, покопавшись в исходниках Qt, пришел к выводу: а не лучше ли не сокращать так перечисления как мы сократили сейчас?

Подозреваю, что все зависит от конкретной ситуации. Например, в QFile перечисление Error имеет общий суффикс, а Permission нет. QIODevice::OpenModeFlag не имеет ничего общего. Думаю, тут исходят из того, если название уникально и не может быть продублировано чем-нибудь, то писать коротко, если может - длинно. С другой стороны: setParity(SerialDevice::SpaceParity) выглядит менее "кузяво", чем setParity::(SerialDevice::Space).

Еще я бы тогда убрал наверное вообше перечисление скоростей, а вместо этого всунул бы метод типа standartBauds() который бы возвращал
список скоростей для данной ОС.
Хотя, хз...

Перечисление лучше оставить. Так у пользователя будет гарантия, что он использует стандартную скорость. А вот идея со standardBauds() (обращаю внимание на букву d) мне нравится.

а как можно открыть порт не задав режим его работы?

Элементарно. Открыть и всё.

>>всунул бы метод типа standartBauds() который бы возвращал
>>список скоростей для данной ОС.
Да это полезно, можно без труда формочки клепать, если метод будет возвращать строки и будет метод который эти же строки скушает для установки скорости.

Никаких строк! Только числа. GUI - не главное!

А что такое le()?

Line Enable, тоже самое что и DSR.

[b-s-a]

>>то он будет работать от настроек по умолчанию
стало быть умалчиваемые настройки есть (не важно ОСьки или библиотеки).

Эти умолчания только при загрузке ОС. Более того, не исключено, что все еще зависит от драйвера. Не знаю как под Windows, но под Linux настройки порта сохраняются после закрытия приложения. Из этого следует, что настройки порта по умолчанию СЛУЧАЙНЫ и на них полагаться не нужно.

[kuzulis]

Под линухом можно задать направление. Под Windows не помню.

А вроде нельзя, flush() это есть tcdrain() !

При этом, с большой долей вероятности пользователь будет задавать 1 стоп и без четности (я уж не говорю про реакцию на ошибку четности, так как это вообще мало кому нужно). Так зачем его заставлять это делать каждый раз путем вызова 4-5 методов?

См. http://wiki.crossplatform.ru/index.php/Designing_Qt-Style_C%2B%2B_APIs#.D0.9B.D0.BE.D0.B2.D1.83.D1.88.D0.BA.D0.B8_.D1.83.D0.B4.D0.BE.D0.B1.D1.81.D1.82.D0.B2.D0.B0
"Ловушки удобства "

Из этого следует, что настройки порта по умолчанию СЛУЧАЙНЫ и на них полагаться не нужно.

ИМЕННО!  Никто не говорит что на них нужно полагаться.
Всё-равно пользователь установит сам свои настройки.
НО! Я против предустановки параметров порта при его открытии и т.п. ,
т.к. вдруг пользователю понадовится не 1 стоп бит и 8 бит данных - а иное значение,
и получается, что классу приходится дважды изменять параметры:
один раз при открытии/конструкторе
второй раз - пользователь меняет.

Предлагаю вообще при открытии порта всё оставить так как есть сейчас:
определяются текущие параметры по умолчанию и ими заполняются внутренние переменные класса. И всё!
И пользователь уже сам решает: или его удовлетворяет то что определилось, или он выборочно сам установит то что ему нужно.