QNetworkConfigurationManager и QThread

[Igors]

Хотелось бы кстати уточнить - а почему? В чем разница наследования QThread от moveToThread. Как мне кажется - это как бы 2 варианта реализации одного и того же в итоге. Просто moveToThread проще что ли в записи, чем класс от QThread наследовать. Или все же есть какие то принципиальные отличия?

Просто "так пишут" (в статьях и.т.п) - и многие считают хорошим тоном этому следовать

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

Не используя наследование, можно не заботиться о многих вещах, в т.ч. и о иерархии отношений объектов класса, выполняющегося в отдельном потоке. Все parent'ы указываем как обычно. И при этом можем легко перемещать выполняющийся класс из главного потока в параллельный и обратно даже в то время, когда оба из них выполняются. Например:

А чего же в в приводимом Вами примере MyClass создается с parent = NULL? Видимо потому что иначе его не переместить безболезненно, точно так же как и в первом посте. Не видно чем наследование виновато. Да, оно необязательно, а может и не нужно, но никаких монстров и проблем оно не создает.

Чужие мысли могут выглядеть очень красиво (в отличие от своих, корявых) - но они всегда останутся чужими 

[alexis031182]

Просто "так пишут" (в статьях и.т.п) - и многие считают хорошим тоном этому следовать

Конечно пишут, в т.ч. и в справке Qt (крутим страницу вниз до конца). Но определяющим фактором к использованию альтернативного метода, конечно же, должно быть не наличие подобных рекомендаций на официальной странице, а понимание того, что в каждом конкретном случае является наиболее подходящим.

А чего же в в приводимом Вами примере MyClass создается с parent = NULL?

Это основное неприкасаемое условие к перемещаемому объекту.

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

Да ничем не виновато. Просто есть объект-инструмент, а есть объект, над которым этот инструмент производит действие. Мешать одно с другим, получается, вроде как не логично.

Да, оно необязательно, а может и не нужно, но никаких монстров и проблем оно не создает.

Подобной проблемы, что возникла у ТС не появилось бы в случае неиспользования наследования.

Чужие мысли могут выглядеть очень красиво (в отличие от своих, корявых) - но они всегда останутся чужими 

А это вообще непонятно к чему сказано. Я где-то указывал авторство к приводимому коду?

[Igors]

Просто есть объект-инструмент, а есть объект, над которым этот инструмент производит действие. Мешать одно с другим, получается, вроде как не логично.

В Вашем примере неясно зачем городить еще и MyClass если можно спокойно разместить данные в наследнике QThread. Мол, парента может иметь - несерьезно, это не UI и роль парента невелика (если не ноль). К тому же MyClass все равно без парента.

Я бы попробовал обосновать так: а почему мы считаем что функциональность должна обязательно выполняться в отдельной нитке? А вдруг нам надо перенести этот функционал в главную? Или в др нитку которая еще что-то выполняет? Тогда мы никак не выкрутимся если унаследовались от QThread.

И вообще можно просто и честно сказать: "ото написано, наверное не дураки писали. Перепроверять и думать - оно мне надо? Проще воспользоваться, тем более это легко". Не вижу ничего плохого в этом (пусть утилитарном) подходе. Сплошь и рядом всем так приходится так делать - иначе просто не выплыть "в бурном информационном потоке".

[alexis031182]

В Вашем примере неясно зачем городить еще и MyClass если можно спокойно разместить данные в наследнике QThread.

Что значит "городить ещё"? Размер кода по сути тот же: что наследуем QThread - создаём новый класс, что идём по другому пути - то же самое (ну разве что пара строк на connect).

И да, можно спокойно разместить данные в наследнике QThread, кто же против

Мол, парента может иметь - несерьезно, это не UI и роль парента невелика (если не ноль). К тому же MyClass все равно без парента.

Не очень понял

Я бы попробовал обосновать так: а почему мы считаем что функциональность должна обязательно выполняться в отдельной нитке? А вдруг нам надо перенести этот функционал в главную? Или в др нитку которая еще что-то выполняет? Тогда мы никак не выкрутимся если унаследовались от QThread.

Это побочная/параллельная/дополнительная ситуация. Я не стал её приводить как аргумент, поскольку такое в основном редко необходимо, да и к вопросу ТС очевидно не имеет отношения.

И вообще можно просто и честно сказать: "ото написано, наверное не дураки писали. Перепроверять и думать - оно мне надо? Проще воспользоваться, тем более это легко". Не вижу ничего плохого в этом (пусть утилитарном) подходе. Сплошь и рядом всем так приходится так делать - иначе просто не выплыть "в бурном информационном потоке".

Igors, не ведаю, с чего Вы вдруг взяли на себя это тяжёлое бремя выводить всех и каждого (либо по какой-то причине только меня) на чистую воду, однако могу всецело Вас заверить, что не имею отношения к тому подтексту, что так настойчиво Вами копируется из поста в пост.

[Bepec]

Насчёт наследования и moveToThread - скажу проще:

1) наследник от QThread и moveToThread(this) в конструкторе
2) свой класс и moveToThread(поток) в своих классах

1) позволяет избежать десятков проблем на мелких проектах, исчезает необходимость в "распределении объектов" по потокам. Да и впоследствии нет нужды искать - где же ты кинул класс в поток и как.

2) позволяет распределять нагрузку на потоки, в больших проектах. Или же когда набор действий, выполняемых в другом потоке, не является постоянным. Переменные, которые указываются пользователем, к примеру, и действия с ними.


Оба способа равнозначны, но я использую 1.

Почему?

Потому что я создаю максимум 1-2 потока в программе. И если появляется необходимость переноса функционала (а она возникает очень часто), то достаточно просто подключить 2 файлика в проект и прописать параметры в конструктор.

Второй способ я не использую, ибо не встречал ещё настолько серьёзного проекта.
 
PS первый способ короче, понятнее для "чужого" программиста.
Второй способ длиннее, непонятнее, но более гибкий в рамках больших задач.

А нужна ли вам его гибкость?