Куда вам точнее надо? Ваш пример не описывает проблемы. Чем вас в первом случае не устраивает ответ? Могу сказать, что double точнее представляет числа, но сомневаюсь, что такой ответ вам подходит. То, что вы мыслите в десятичной системе не значит, что двоичная неточная.
И советую вам оформить код в тег code . Читать сложновато скриншоты.
Sazoks, так в этом то и прикол, что у сокетов различные буферы для записи и чтения. Тоесть чтобы отправить вы пишете в одно место, а читаете из другого.
А в пределах вашей программы это не может одновременно произойти , так как у вас будет один поток и в единый момент времени вы либо читаете, либо пишете, одновременно никак.
Если прямо хочется обрабатывать сообщения в другом потоке, то можно просто само сообщение и обрабатывать, а не создавать сокет и читать из него. Пусть исходный сокет так и читает данные и просто сигналит о чтении, посылает сообщение в другой поток.
Я на всякий случай уточню, вполне возможно, что не могут существовать два QTcpSocket-а с одинаковым дескриптором, так как они читают из него в свой локальный буфер и поэтому до второго не доходят данные, но не уверен в подобной реализации. Опять же чтение из одного дескриптора из разных потоков не факт что безопасно.
Да и qt не советует использовать QTcpSocket в потоках, так как он условно асинхронный.
Либо второй вариант, проблема может быть в потоке и его eventLoop.
Sazoks, я про это и говорю, в главном потоке вы создаете connect, который читает данные в исходный сокет, потом создаете второй, но connect остается, так ведь? И получается что исходный сокет читает все данные и второму ничего не остается. Метод connect возвращает QMetaObject::Connection с помощью которого потом можно сделать disconnect для исходного сокета от сигнала readyRead. Либо я до сих пор не понял в чем проблема.
Вы же сами подключаете сигналы к слотам, просто одним сокетом читайте, другим пишите. Так же у QAbstrackSocket в метод connectToHost передается флаг, можно выбрать хотите вы только читать или только писать.
Мне кажется, что у вас тут проблема как минимум с тем, что функция делает слишком много(кастует, читает, потом еще пишет) и из-за этого применимость, гибкость ее и вообще читаемость сильно падает. Через несколько месяцев вам же самому будет трудно читать и отлаживать такой код, даже если кол-во таких методов не вырастет.
Не уверен, что хорошо это советовать, так как в c++ функциональный код особо не читаем, но избавиться от подобного можно с помощью связывания. Про это говорится с минуты 15, но лучше все посмотреть. Так у вас будет несколько мелких функций, которые тупо легче читать и один класс который это все свяжет. Довольно гибко, но на любителя.
А по поводу обучения, так с этим так же как и везде, практиковаться и решать проблемы.
Евгений Шатунов, ок, не правильно выразился, main быть может, как может и не быть. Просто по мне это немного усложняет логику использования библиотек, либо если добавить две таких статических библиотеки может возникнуть казус. И вроде, в среднем, так не делают. Заставить пользователя инициализировать что-либо перед выполнением можно менее извращенными способами.
И советую вам оформить код в тег code . Читать сложновато скриншоты.