Russian Qt Forum

есть ли класс реализующий QIODevice через stdin stdout?

нужно чтоб write(QByteArray) работал через stdout,
readyRead(), readAll() - stdin

bool QFile::open(FILE * fh, OpenMode mode) (http://doc.qt.io/qt-4.8/qfile.html#open-4)

Текстовый поток тоже работает с stdin и stdout. Думаю, что и QDataStream тоже.

почему-то не возбуждается сигнал QIODevice::readyRead. (Данные пишутся в дочерний процесс)
проект во вложении

Тут у вас в релиз версии файл не откроется

C++ (Qt)
Q_ASSERT(_in->open(stdin, QIODevice::ReadOnly));

Вам нужно сигналы ловить от _childProc

C++ (Qt)
connect(_childProc, SIGNAL(readyRead), SLOT(onReadyRead));

А ещё, в вашем случае, будет лучше читать поток через QProcess::readAllStandardOutput()

секундочку... почему от _childProc? Родительский процесс шлёт данные дочернему. В дочернем процессе через stdin я надеюсь их услышать и прочитать.

Текстовый поток не подойдёт, слаться будут сериализованные объекты. QDataStream не работает с stdin и stdout.

Заметил ещё один момент. Посылайте

C++ (Qt)
_childProc->write("qwerty\n");

Давайте предположим, что ваш дочерний процесс это обычный cmd в винде.
Что будет, если вы в командной строке напишете qwerty? Ничего не произойдёт, строка будет дожидаться дальнейшего ввода. Но после того, как вы нажимаете Enter ('\n'), начинается обработка введённой строки. Также и в вашем случае.
Ещё момент. Вы шлёте процессу данные через класс QProcess, все ответы тоже приходят в него. Думаю, что логично использовать для всех операций с дочерним процессом именно QProcess.

cmd - оперирует строками. Для него строка - одна команда. Соответственно он будет ждать символа конца строки. Я делал app на подобие cmd (консольное приложение). Использовал в нём QTextStream. И так же ждал от стандартного потока ввода строки, чтоб выполнить действие. А мог бы и реагировать по каждому посланному байту, не суть...

Сейчас задача другая, наладить межпроцессную коммуникацию. Одно приложение запускает другое. Родительское имеет связь с дочерним через объект QProcess, который реализует интерфейс QIODevice. Для него пофиг что ему пишут в поток, строку или картинку.

Тут Вы меня вообще не правильно понимаете. Да я шлю процессу данные через класс QProcess, но зачем мне в том же приложении из этого же процесса их считывать?! Эти данные нужны в дочернем приложении. Эти два приложения - два узла, они работают в разных процессах, каждый со своей памятью.
Давайте представим что мои приложения работают на разных компьютерах и должны общаться по сети. Мы же не будем писать данные в сокет компьютера1 и вычитывать их из того же сокета?

Наконец-то то-я понял причину. В документации QFile сказано:
бесполезно слушать readyRead().


Исходный вопрос остаётся открытым:
есть ли класс реализующий QIODevice через stdin stdout?
нужно чтоб write(QByteArray) работал через stdout,
readyRead(), readAll() - stdin
.

Ну а чем QProcess не угодил то?

Не относитесь к процессу как к файлу. Если я что-то пишу, то это пишется в stdin, если я что-то читаю, то это читается из stdout или stderr

я перерыл кучу форумов по этому вопросу, и русских и английских, и в каждом есть человек который бегло пробежав по теме, пишет вот точно такое же сообщение)))

Ещё раз. QProcess у меня есть в родительском приложении. С помощью него я могу писать\читать данные в stdin\stdout\stderr  дочернего процесса. А в дочернем приложении, которое ничего не знает про родительское и про QProcess, есть только stdin/stdout/stderr с которыми я надеялся асинхронно работать через интерфейс QIODevice.

Вообщем ситуация пока такая: нет реализации с помощью которой можно асинхронно читать\писать из std потоков. (На этом форуме есть тема, в которой сваяли нечто-подобное в отдельном потоке... Но эта реализация меня не устраивает.). Посему для межпроцессного общения я решил использовать QLocalSocket, а не QProcess в связке с iosteram.

Вы можете привести небольшой пример задачи, которая требовала бы подобной реализации?

Насколько я понял, нет асинхронки, т.е. сигнал readyRead от дочернего процесса не приходит. А синхронно можно получить мертвое зависание если по каким-то причинам дочерний процесс умолк. Его можно вынести в поток (чтобы хоть UI жило), но проблемы это не решает.

Если так то да, это не раз жевалось, и обычный конец - отсылание к boost::asio