Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, Acteon, Вы писали:

A>>Подход 6. Потерялось наследование Concreate от Base.
К>Не потерялось. Base и Concrete — финальные классы.

Все, увидел. Оно просто реализуется через myself(). Я правильно понял?

A>>А зачем класс Concrete дружит с классом friend class BaseT<Base>; ? И кстати, зачем вообще объявлена дружба с классом, от которого мы наследуемся?

К>Затем, что перегружаемый член m_thread (к которому обращается базовый класс) засунут в private:

Да, увидел, понял. А то что Concrete дружит с классом BaseT<Base> вместо BaseT<Concrete> просто ошибка.

A>>Подход 7. В бусте потоки в связке с биндерами очень мощные. Но к сожалению, я вынужден использовать Qt для этих целей. Работаем с тем, что есть, а не с тем чем хочется.

К>Но хотя бы boost:: / std::tr1:: bind можно использовать?

Нет. Проект уже давний, на чем пишут, на том пишут. Но уже раз десять сталкивался с тем, что приходилось писать велосипеды, т.к. в Qt нет того, что есть в бусте. Даже элементарный non_copyable реализован не так как надо.

К>Всегда же можно сделать санки (thunk) в ООП-стиль.
К>[c]
К>template<class Fun> struct FunThread: Thread \\ Ошибочка.
К>{
К> Fun m_fun;
К> explicit FunThread(Fun fun) : m_fun(fun) {}
К> virtual void run() /*override*/ { m_fun(); }
К>};

И получится уже что-то близкое к бустовским потокам. Это уже 11-й раз. За идею спасибо.

A>>В общем пока примерял все подходы, родилась еще одна идея. Унаследовать класс Base от класса Thread. Получилось что-то на подобие вот этого здесь Критика приветствуется.

К>Ну, в принципе, так нередко делают. Когда объект — сам себе представитель потока (или, кстати, представитель окна).
К>Есть два подхода к архитектуре.
К>- с иерархией тяжеловесных объектов, реализующих поведение потоков, окон, и т.п.
К>- с единообразными хэндлами и разнообразными объектами-владельцами, не обязательно связанными в одну иерархию.
К>Для Qt, как и для многих ООП-фреймворков, характерно первое.

К>Тут надо смотреть на цену этого склеивания. Потому что потом расклеить объект на поток и всё остальное будет мучительно.
К>Но если расклеивать не собираешься, то почему бы и нет?

Ясно, спасибо. Разъединять их в будущем не собираюсь. Оставим будущие проблемы — потомкам.