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

[kuzulis]

Только я бы добавил еще промежуточные классы типа "Engine", т.к. такой подход скрывает в реализации "serialport.cpp" платформо-зависимые типы данных и т.п.

Я ниже приаттачил два примера scope_bad и scope_ok, которые демонстрируют этот подход.

В примере scope_bad (который аналогичен нашему текущему подходу) переменные Windows видны в "base.cpp" , что НЕ ПРАВИЛЬНО! Имхо.

В примере же  scope_ok любые платформо зависимые типы данных скрыты через класс BaseEngine, что ПРАВИЛЬНО!
Этот подход был ранее в библиотеке и выполнен.
Также, этим пользуются повсеместно тролли в Qt!

ИМХО, я бы не стал упрощать всё до такой степени как предлагает b-s-a!
Я за оставление структуры от версии "master".

[b-s-a]

1. Почему ты сменил каталог src на lib?

мне показалось более логичным разместить в lib. Так как потом еще будет tests, examples...

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 ничего не должна знать об платформо зависимых вещах.

На то и MR существуют - не нравится, отклоняешь

3. Почему убрал *.pri файл?

Я поменял тип проекта на subdirs - т.е. будет куча независимых подпроектов.

[kuzulis]

b-s-a (а также остальные заинтересованные лица), почитай(те) и выскажись(тесь) по тем доводам которые я привел выше про область видимости.

[asvil]

Ссылочки на MR скидывайте пожалуйста.

Встряну по поводу файловой структуры. Всячески агитирую за nix-style с помесью qt.

Код:

bin - binary
lib - binary
etc - text configs
share - shareable objects
  `translations
  `images
src - sources of modules
  `modules
  `examples
  `tests

Исчезновение *pri сводит на нет возможность вкомпиливания в приложение библиотеки. Нет ну можно конечно выкрутить статической библиотекой.

[kuzulis]

Ссылочки на MR скидывайте пожалуйста.

http://gitorious.org/qserialdevice/qserialdevice/merge_requests

Исчезновение *pri сводит на нет возможность вкомпиливания в приложение библиотеки. Нет ну можно конечно выкрутить статической библиотекой.

Люто плюсую

[lit-uriy]

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

[b-s-a]

b-s-a (а также остальные заинтересованные лица), почитай(те) и выскажись(тесь) по тем доводам которые я привел выше про область видимости.

Не вижу смысла усложнять структуру и увеличивать потребление ресурсов ради убирания из области видимости реализации платформозависимых элементов. Тот же QFile содержит такое усложнение из-за использования общих с другими классами элементов. А вот, например, QSettings сделан иначе.

Исчезновение *pri сводит на нет возможность вкомпиливания в приложение библиотеки. Нет ну можно конечно выкрутить статической библиотекой.

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

[kuzulis]

Что скажут остальные?

[asvil]

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

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

[lit-uriy]

>>Никто не мешает выделить pri из pro.
вот и выделите его сразу.

>>Я против включения  в репозиторий каталогов сборки и готовых файлов.
pri-файл к ним никакого отношения не имеет.

[b-s-a]

>>Я против включения  в репозиторий каталогов сборки и готовых файлов.
pri-файл к ним никакого отношения не имеет.

я говорил уже о другом - лень было процитировать часть исходного сообщения.

[kuzulis]

Ну так об области видимости кто-нить что-нить выскажет ещё?
Или я не дождусь...

ЗЫ: Хотелось бы "услышать" ещё тов. BRE и Rcus

[Rcus]

То есть с одной стороны пара условных секций для определения платформозависимых полей и инициализации в общем конструкторе. При этом структура довольно проста, но не позволяет иметь несколько реализаций порта в одной сборке (невелика потеря с моей точки зрения, но может пригодиться при работе с FT232 через её API, а не VCP драйвер). А расширение видимости платформенных определений в общую часть приватного класса - небольшая цена за простоту (главное что это не проникает в public header).
С другой стороны вызов проходит через Base::method -> BasePrivate::method -> BaseEngine::method -> BaseEnginePrivate::method от кого скрываемся так сказать?

[kuzulis]

главное что это не проникает в public header

Т.е. если приникает в базовую реализацию base.cpp - то и фик с ним?

Rcus, так, всё-таки, каков твой вердикт?

[BRE]

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