Обозначается временнáя сложность как «О» (читается как «О большое»).
Эту фразу можно понять так, будто «О большое» создано исключительно для этого обозначения. Но на самом деле в понятие «О большое» не заложены ни временная сложность, ни сложность как таковая. Это широко используемое математическое обозначение (wiki).
Есть у нас местный сервис доставки еды, в котором всегда перезванивают и зачитывают мой заказ. Сначала пробовал в комментарии писать «можно не звонить», но всё равно позвонили, спокойно зачитали, что можно не звонить, и спросили, всё ли правильно. От такого поворота был сильно удивлен. Сложилось впечатление, что оператор там вообще не думает и действует по скрипту.
Поэкспериментировал. Оказывается, с std::vector действительно не понимает, а вот с QVector (и прочими qt-шными контейнерами) понимает прекрасно. В целом действительно модель кода слабовата, но работает она быстро и для многих вещей ее хватает.
Берется какая-то физическая теория, которая способна предсказать время жизни протона. Поскольку процесс вероятностный, то время жизни — это не конкретное число, а распределение вероятности. Затем берется большой объем вещества (в котором много протонов) и проводятся наблюдения. Если ни один протон не распался, то на основе теории делается оценка снизу, например: с вероятностью 90% время жизни протона больше 1.29×1034 лет. Естественно, никто не гарантирует, что какая-то частица распадется точно в заданный момент. И никто не даст гарантий, что используемая физическая теория верна. Но это пока всё, что мы можем сделать.
Для объектов стека метода run() не имеет смысла применение moveToThread(), т.к. это — переменная метода (возможно, я чего, то не понял).
Для объектов, созданных в некотором потоке, не имеет смысл вызывать moveToThread, потому что они по умолчанию уже принадлежат этому потоку. Кроме того, если вы переопределяете QThread::run и не запускаете event loop (а в реализации по умолчанию он запускается), то moveToThread теряет смысл, потому что единственное, на что он влияет, — в каком потоке будут вызываться обработчики событий и слоты объекта, а при отсутствии event loop в потоке они вызываться не будут вообще.
Указатели нельзя физически (если, конечно, не применить memmove()) переместить в другой поток: память у потоков общая, да и не имеет смысла. Вроде, это видно из исходников QT. Речь идёт о смене владельца указателя.
Указатель — это просто число, и его легко скопировать в другой поток. Затем можно использовать этот объект одновременно или по очереди в двух потоках. И это в общем случае не зависит от того, где и как объект создан.
Понятие владельца весьма расплывчато. Parent object в Qt — это другой объект, который удалит наш объект вместе с собой. Thread affinity, как я уже сказал, определяет, в каком потоке обрабатываются события объекта. И ни один из этих параметров не запрещает использовать любой объект в любом другом потоке в то же время. Правда, для безопасного использования желательно, чтобы объект был thread-safe и его никто не удалил в процессе обработки.
В статье затронуто очень много разных вопросов — и потоки в Qt, и конечные автоматы, и libusb. Причем связаны между собой они очень слабо. Если бы у меня была подобная задача, я бы предпочел найти отдельную обстоятельную статью по каждому вопросу, а не одну, где всё вместе. Поэтому не очень понятно предназначение статьи.
Переопределив метод QThread::run(), знайте, что все объекты, созданные в нем, будут недоступны из вне, т.к. созданы в стеке метода run() (хотя и это можно обойти).
Поясните эту фразу. Во-первых, если объект создан через new, он будет помещен в heap, а не стек. Во-вторых, если объект создан на стеке, он будет на том же самом стеке независимо от того, переопределили вы QThread::run() или используете moveToThread. В-третьих, независимо от того, где создан объект, указатель на него можно переместить в любой другой поток (будет ли это безопасно — другой вопрос). Непонятно, о каком «из вне» идет речь.
Теперь про завершение потоков. Если в потоке произойдет segfault или событие аналогичной катастрофичности, то упадет весь процесс целиком, и сделать тут мало что можно. А чтобы справиться с неотловленными исключениями, необязательно использовать обертку для QThread. Достаточно в QThread::run сделать безусловный try/catch. Точка выхода из потока тут тоже одна — это завершение метода QThread::run. После этого Qt самостоятельно завершит поток.
И на всякий случай замечу, что правильно zero, а не zerro.
Я много работал с Qt Model/View и делал на нем разные нетривиальные вещи. Чудовищным я бы его не назвал. Он достаточно сложен в понимании и требует вдумчивого чтения документации, но свою задачу — отделение представления от данных — в определенных рамках выполняет хорошо. Опять же, нужно понимать, что этот фрагмент Qt сделан не для глобальных универсальных применений Model/View, а для обеспечения возможности его применения в существующих виджетах (в том числе и табличных), предоставляемых Qt. Без этого отделить представление от данных было бы просто невозможно.
На самом деле так себе. Мне обычно приходится прочитать всё или пробовать Ctrl+F с разным текстом, чтобы понять, как они назвали нужный параметр и куда его положили. Не знаю, как сделать лучше, но это точно не идеал.
Эту фразу можно понять так, будто «О большое» создано исключительно для этого обозначения. Но на самом деле в понятие «О большое» не заложены ни временная сложность, ни сложность как таковая. Это широко используемое математическое обозначение (wiki).
Указатель — это просто число, и его легко скопировать в другой поток. Затем можно использовать этот объект одновременно или по очереди в двух потоках. И это в общем случае не зависит от того, где и как объект создан.
Понятие владельца весьма расплывчато. Parent object в Qt — это другой объект, который удалит наш объект вместе с собой. Thread affinity, как я уже сказал, определяет, в каком потоке обрабатываются события объекта. И ни один из этих параметров не запрещает использовать любой объект в любом другом потоке в то же время. Правда, для безопасного использования желательно, чтобы объект был thread-safe и его никто не удалил в процессе обработки.
Поясните эту фразу. Во-первых, если объект создан через new, он будет помещен в heap, а не стек. Во-вторых, если объект создан на стеке, он будет на том же самом стеке независимо от того, переопределили вы QThread::run() или используете moveToThread. В-третьих, независимо от того, где создан объект, указатель на него можно переместить в любой другой поток (будет ли это безопасно — другой вопрос). Непонятно, о каком «из вне» идет речь.
Теперь про завершение потоков. Если в потоке произойдет segfault или событие аналогичной катастрофичности, то упадет весь процесс целиком, и сделать тут мало что можно. А чтобы справиться с неотловленными исключениями, необязательно использовать обертку для QThread. Достаточно в QThread::run сделать безусловный try/catch. Точка выхода из потока тут тоже одна — это завершение метода QThread::run. После этого Qt самостоятельно завершит поток.
И на всякий случай замечу, что правильно zero, а не zerro.
А как же «на всем знакомый мотив», «во всем известном городе»? Ох, сложно с этими заменами.