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

[poru]

А теперь филосовский вопрос.
1. Если ОС не позволяет записать неверные настройки в DCB, тогда сможем ли мы, когда либо получить такие же неверные настройки?
2. Если у меня есть driver к микросхеме, обладающей расширенными возможностями, тогда detectDefaultSettings мне наставит Unknown's. Как дальше быть?

Это я к тому, что от Unknown's надо как то избавляться. Получается, что мы вводим искуственные ограничения на те области, которые однозначно до конца не знаем. (А кто-то может и знает)

[kuzulis]

1. Если ОС не позволяет записать неверные настройки в DCB, тогда сможем ли мы, когда либо получить такие же неверные настройки?

Вполне. Так и происходит. Проверь. Особенно в *nix.
Хотя может это из-за ошибок в этом самом детекторе.
Если удастся однозначно детектить состояние на всех платформах- то от Unknown's можно и избавиться.

2. Если у меня есть driver к микросхеме, обладающей расширенными возможностями, тогда detectDefaultSettings мне наставит Unknown's. Как дальше быть?

Мы не рассматриваем расширенные возможности, т.к. это частности, все возможные варианты м/сх и т.п. не отследишь и не учтешь. 
Ну выставит оно Unknown's - ну и что, можно далее выставить что нужно.

Поэтому пока принудительно ограничиваем область на всякий случай.

ЗЫ:
Вот даже сейчас проверил в Win7, открыл порт, а оно мне выдало что FlowControl unknown,
хотя такого ведь не может быть?

[b-s-a]

kuzulis, напиши с список что сделал все что было велено. Кстати, а кто третий разработчик?

2. Если у меня есть driver к микросхеме, обладающей расширенными возможностями, тогда detectDefaultSettings мне наставит Unknown's. Как дальше быть?

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

[kuzulis]

kuzulis, напиши с список что сделал все что было велено. Кстати, а кто третий разработчик?

Ну я написал, что зарегался. А что еще то?
Насчет третьего разработчика - пока ХЗ.

[b-s-a]

в логах гиториуса только ты и я? Или есть еще кто?

[kuzulis]

Если по ветке 2.0, то только я, ты и
один раз по мелочи, типа этого
Кстати, в логах есть unknown - это тоже я (ток ХЗ почему unknown) .

Если по старой ветке, то я, ты, Юра (lit-uriy) засветился с самого начала (он помогал перенести проект из SVN в GIT.),
ну и из SVN еще некий Костя.

Остальные просто как клоны или висящие MR.

[poru]

Ну выставит оно Unknown's - ну и что,

Тем самым вы обрезаете возможность узнать, а что же там было!
А вот для каких целей мне нужно знать то значение, это уже моё дело.

[kuzulis]

Тем самым вы обрезаете возможность узнать, а что же там было!

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

[poru]

Тогда по порядку.
Rate - Можем ли отобразить пользователю начальное значение скорости? Можем. Пусть там да же будет сплошной хаос. Как-то это повлияет в дальнейшем? Возможно, но это проблема программиста, пишущего какое то решение. Зачем закрывать это поле UnknownRate-ом? И то только для одной платформы.
DataBits - пусть мы получим 9. И что? Ну скажет программист юзеру, что в настройках порта полная ересь. А дальше как хочет. Зачем тогда закрывать UnknownDataBits-ом?
Parity - вопрос несколько сложнее, надо посмотреть более детально.
StopBits - элементарный вопрос, для никсов 2 варианта, для винды - несколько больше  Почему бы не показать на форме значение отличное от 3х вариантов. Кому то плохо станет?
FlowControl - вот, пожалуй единственный аргумент в вашу пользу. Тут я не спорю.

[b-s-a]

poru, можешь быть конкретнее. Что твое хитрое устройство выдает?

[poru]

Не буду конкретизировать. Выскажу свои соображения.
1. Отказаться от всех Unknown's. Причины уже описывались.
2. Так как нет Unknown's - не понадобятся методы detectDefaultSettings и им подобные.
3. Отказаться от сохранения и восстановления старых настроек. Оставить это на усмотрение другим программистам. Хотят сохранят, хотят востановят, это их дело. Или хотя бы предоставить возможность.
4. Предоставить возможность получать указатель на структуры типа DCB и пр. Вдруг комуто понадобится их детальный анализ.
5. Минимизировать использование дублирующих переменных, к примеру m_dataBits, для них и так уже выделена пямять.
6. Не инициализировать параметры в кострукторе. Их значения будут иметь смысл только после открытия порта.

Удачи с интеграцией в Qt.
 

[kuzulis]

1. Отказаться от всех Unknown's. Причины уже описывались.
2. Так как нет Unknown's - не понадобятся методы detectDefaultSettings и им подобные.

Нуну.. вот открыл ты порт. И что покажешь пользователю?
Как в случае без detectDefaultSettings ты покажешь что же действительно установлено в текущий момент?

3. Отказаться от сохранения и восстановления старых настроек.

Не согласен. Открыл порт. Поработал с ним. И перед закрытием будь добр
восстанови все как было до открытия. Не тобой оно было до этого установлено
и не тебе это менять.
 

Оставить это на усмотрение другим программистам. Хотят сохранят, хотят востановят, это их дело.
Или хотя бы предоставить возможность.

Так вообще то оно сейчас реализовано.
Плохо код смотрел.

4. Предоставить возможность получать указатель на структуры типа DCB и пр. Вдруг комуто понадобится их детальный анализ.

Аха, для *nix на termios, для Symbian на TCommConfig...
Ну вот нафига? Что это за зоопарк будет? Скажы ты мне.
Убеди!

5. Минимизировать использование дублирующих переменных, к примеру m_dataBits, для них и так уже выделена пямять.

Где оно дублируется?

6. Не инициализировать параметры в кострукторе. Их значения будут иметь смысл только после открытия порта.

Начальная инициализация переменных еще никому ничего плохого не сделала.
И выигрыш "производительности" или "размера" или чего там, от этого сомнителен.


Ждем остальных. Пусть выскажутся.  

[b-s-a]

1. не уверен, что для всех пунктов подойдет. Но можно рассмотреть такой вариант.
2. согласен с kuzulis
3. согласен с kuzulis
4. согласен с poru, пример реализации подобного можно найти в QWidget.
5. дублирования нет. я в свое время тоже хотел так, но при реализации не получилось.
6. начальная инициализация еще никому не повредила.

[kuzulis]

4. согласен с poru, пример реализации подобного можно найти в QWidget.

Может тогда лучше отдавать дескриптор порта (добавить метод типа descriptor().
А программист, если ему уж так нужно будет что-то особенное переконфигурить, сам по этому дескриптору получит необходимые ему DCB,
COMMTIMEOUTS и т.п.

Как такой вариант?

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

Поэтому, склоняюсь к дескриптору. Хотя, для симбиана дескриптор - это отдельный класс.

Хотя, можно возвращать указатель на дескриптор в виде (void *),
а уже в конкретной платформе программист сам будет приводить этот указатель или к HANDLE или к int или к RComm.

Не знаю..что-то не горю желанием.

[b-s-a]

В любом случае, добавить новый метод можно всегда. А вот удалить...