Qt 5: как сделать «чистый с ++» клиентский сокет?

Question

Qt 5: как сделать «чистый с ++» клиентский сокет?

0

Я создаю приложение QtQuick, и мне нужен TCPSocket, который опросает устройство и заполняет структуры данных, которые я хочу показать. Я нашел много образцов о сокетах и виджетах Qt 5, но я не могу создать сокет в качестве класса C++, который не был получен из QObject.

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

Parduz 17 дек. 2013, в 17:36

Источник

1

Вы смотрели на QTcpSocket?
jalf 17 дек. 2013, в 16:13
0

Да. Моей отправной точкой был пример "FortuneCookie", который использует QTcpSocket. Я сократил почти весь код до тех пор, пока не получил QObject, который после создания получает имя локального хоста и другие основные свойства с моей машины. Я пытаюсь избежать производного класса QOBject, но я не знаю, как создавать «события» между моим кодом C ++ вместо сигналов и слотов для QML. Кроме того, некоторые методы перестали компилироваться, пока класс больше не является QObject
Parduz 17 дек. 2013, в 16:17
1

Либо вы используете Qt, либо нет. Зачем беспокоиться о Qt, если вы не хотите его использовать? Идея, что QObjects как-то плохи, обычно ошибочна. Они делают именно то, что вам нужно. Вы хотите написать асинхронный код, который даст вам хороший пользовательский опыт. Вам нужны QObjects, QEvents и цикл обработки событий, и все это влечет за собой. Кроме того, у вас неверное представление о том, что такое сокет. Розетки тупые. То, что вы называете сокетом, все остальные в мире называют сетевым клиентом. Если вы не хотите использовать сгенерированный moc код, обычно это потому, что у вас нет дескриптора в вашей системе сборки. Изучи это, используй это.
Kuba Ober 17 дек. 2013, в 16:26
0

1-й: мне очень жаль, что мой английский недостаточно хорошо Я делаю все возможное. 2-й: «Изучи это»: это именно то, что я пытаюсь сделать. Итак, вот вопрос, который я задаю вам сейчас: разве классы QObject не созданы для использования в файлах QML? Или я не прав, и я их неправильно понял, и я должен использовать производные классы QObject, даже если пользовательский интерфейс не должен их использовать? Моя цель - создать пользовательский интерфейс, который не знает, кто передает данные (последовательный порт, tcp-клиент или симуляция) ... вот почему я не хотел использовать QObject ... на основе Предположение, что они существуют для использования в пользовательском интерфейсе QML. Спасибо
Parduz 17 дек. 2013, в 16:39
5

QObject не является классом, специфичным для GUI, он полезен всякий раз, когда вам нужен объект, который может использовать сигналы и слоты. QObject восходит к исходной версии Qt, он намного старше QML и никоим образом не зависит от QML.
Jeremy Friesner 17 дек. 2013, в 17:02
0

Я думаю, что основополагающая путаница делает ценный вопрос, поэтому я отредактировал его, и я надеюсь, что другие согласятся, и Джереми представит свой комментарий для ответа.
Tod 17 дек. 2013, в 20:44
0

@JeremyFriesner: сигналы и слоты на самом деле не единственные функции для QObject, поэтому ваши рассуждения частичны. Также обратите внимание, что для правильного QML'а вам нужны QObjects в текущий момент. Это может запутать ОП.
lpapp 17 дек. 2013, в 21:34
0

@KubaOber: На самом деле, вы можете использовать некоторые классы Qt без QObjects. Вам не нужно добавлять QObject для наследования только ради QObject.
lpapp 17 дек. 2013, в 21:37
0

@FabioCalzolari: можно ли будет показать код, который вы пробовали до сих пор?
lpapp 17 дек. 2013, в 21:38

Показать ещё 7 комментариев

Теги:

c++

qt

sockets

qtnetwork

1 ответ

Ещё вопросы

Да. Моей отправной точкой был пример "FortuneCookie", который использует QTcpSocket. Я сократил почти весь код до тех пор, пока не получил QObject, который после создания получает имя локального хоста и другие основные свойства с моей машины. Я пытаюсь избежать производного класса QOBject, но я не знаю, как создавать «события» между моим кодом C ++ вместо сигналов и слотов для QML. Кроме того, некоторые методы перестали компилироваться, пока класс больше не является QObject
Либо вы используете Qt, либо нет. Зачем беспокоиться о Qt, если вы не хотите его использовать? Идея, что QObjects как-то плохи, обычно ошибочна. Они делают именно то, что вам нужно. Вы хотите написать асинхронный код, который даст вам хороший пользовательский опыт. Вам нужны QObjects, QEvents и цикл обработки событий, и все это влечет за собой. Кроме того, у вас неверное представление о том, что такое сокет. Розетки тупые. То, что вы называете сокетом, все остальные в мире называют сетевым клиентом. Если вы не хотите использовать сгенерированный moc код, обычно это потому, что у вас нет дескриптора в вашей системе сборки. Изучи это, используй это.
1-й: мне очень жаль, что мой английский недостаточно хорошо Я делаю все возможное. 2-й: «Изучи это»: это именно то, что я пытаюсь сделать. Итак, вот вопрос, который я задаю вам сейчас: разве классы QObject не созданы для использования в файлах QML? Или я не прав, и я их неправильно понял, и я должен использовать производные классы QObject, даже если пользовательский интерфейс не должен их использовать? Моя цель - создать пользовательский интерфейс, который не знает, кто передает данные (последовательный порт, tcp-клиент или симуляция) ... вот почему я не хотел использовать QObject ... на основе Предположение, что они существуют для использования в пользовательском интерфейсе QML. Спасибо
QObject не является классом, специфичным для GUI, он полезен всякий раз, когда вам нужен объект, который может использовать сигналы и слоты. QObject восходит к исходной версии Qt, он намного старше QML и никоим образом не зависит от QML.
Я думаю, что основополагающая путаница делает ценный вопрос, поэтому я отредактировал его, и я надеюсь, что другие согласятся, и Джереми представит свой комментарий для ответа.
@JeremyFriesner: сигналы и слоты на самом деле не единственные функции для QObject, поэтому ваши рассуждения частичны. Также обратите внимание, что для правильного QML'а вам нужны QObjects в текущий момент. Это может запутать ОП.
@KubaOber: На самом деле, вы можете использовать некоторые классы Qt без QObjects. Вам не нужно добавлять QObject для наследования только ради QObject.
@FabioCalzolari: можно ли будет показать код, который вы пробовали до сих пор?

Kuba Ober · Answer 1 · 2013-12-17T19-45-00.000Z

Вопрос почти не является вопросом Qt, а вопросом сетевого программирования C++. Я понимаю, что вы явно не любите явно использовать пользовательские классы QObject -derived, так как вы не хотите запускать moc как часть процесса сборки. В то время как можно было бы утверждать, что так плохо в этом, так как moc запускается очень много во время построения Qt собственно, отпустите с тем, что было задано на данный момент.

Если вы ищете чистую сеть C++, отличную от Qt, то Boost ASIO является очень надежным решением.

Если вы хотите использовать Qt-сеть без специального класса QObject -derived, вы можете запустить код в отдельном потоке и использовать блокировку вызовов QTCPSocket. В конце концов, это QIODevice и предлагает блокирующий интерфейс.

В конце концов, вы получаете некоторую структуру данных, которая заполняется и должна быть передана QML.

Логически ваши данные - это модель данных, а представление - в QML-коде. Вы можете использовать QStandardItemModel для этого - то есть, если вы пишете истинный код модели, как и в случае, если данные будут меняться со временем. Опять же, вы повторно используете существующий класс QObject -derived, не производя свой собственный, без написания каких-либо пользовательских сигналов или слотов.

Обходным решением для малоимущего человека является принятие QObject и размещение данных в нем с помощью динамической системы свойств через QObject::setProperty. Я не помню, чтобы, если динамические изменения свойств видны через движок QML, вам нужно будет проверить это или просто рассматривать такие объекты как константы.

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