Хочется создать дополнительную консоль, с которой связать потоки ввода и вывода. То есть помимо основной консоли (из которой была запущена программа, и с которой работают stdin и stdout), хочется иметь вторую консоль. Есть ли в c++ подобный функционал? Кроме различных хитростей с qt-шными формами текстового ввода/вывода.

Здравствуйте, Кузнец, Вы писали:

К>Есть ли в c++ подобный функционал?
Нет, конечно. Вещь слишком узкая, платформоспецифичная и кое-где не имеющая смысла.

Если нужна новая консоль, то создай её средствами ОС или сделай свой аналог (ну через тот же qt, если ты его знаешь и используешь).

Здравствуйте, Кузнец, Вы писали:

К>Хочется создать дополнительную консоль, с которой связать потоки ввода и вывода. То есть помимо основной консоли (из которой была запущена программа, и с которой работают stdin и stdout), хочется иметь вторую консоль. Есть ли в c++ подобный функционал? Кроме различных хитростей с qt-шными формами текстового ввода/вывода.

Есть в разных ОС. Тебе под какую надо? Или тебе надо универсальное решение?

С универсальным могут быть проблемы с тем, что в разных ОС консоли умеют разное. Например, как ты планируешь получать выдавать wchar_t туда?
Кроме того в консоли можно много чего делать, Ctrl+C нажимать, например. Что должно происходить по всяким таким доп. событиям в доп консоли?
Все ли обработчики таких событий в твоей программе и во всех используемых библиотеках будут готовы к таким событиям в побочной консоли?..

Как совместимый вариант могу предложить написать простое консольное приложение, которое будет из командной строки брать хендел трубы на вход и трубы на выход, и перенаправлять выход на консоль, а ввод с консоли перенаправлять в выходную трубу. Ну и какой-то простой способ завершиться.
Ну а с клиентской стороны создавать две трубы наследуемые, использовать их в качестве тех самых потоков, и запускать это приложение с этими трубами в качестве параметров...

Возможно такую библиотеку кто-то уже и написал, кстати.

Здравствуйте, Erop, Вы писали:

E>Есть в разных ОС. Тебе под какую надо? Или тебе надо универсальное решение?

Универсальное необязательно (хотя, если оно есть, лучше универсальное, но врятли оно существует). Под Linux Debian нужно.

Вообще эта консоль нужна для очень простого функционала — в большом проекте (99% которого пишу не я) работает несколько моих классов, хочется иметь возможность давать им отладочные команды, например в процессе работы запросить состояние, вот я и хотел сделать терминал, который бы общался чисто с этими классами (вернее с одним главным — наблюдателем, который и раздавал бы команды тем, кому они предназначены). Если это совместить с консолью основной программы, то во-первых будет треш из-за смешивания логов разных компонент ПО, во-вторых скорее всего консоль будет ожидать ввода, и этим попросту остановит выполнение программы, что недопустимо.

E>С универсальным могут быть проблемы с тем, что в разных ОС консоли умеют разное. Например, как ты планируешь получать выдавать wchar_t туда?
E>Кроме того в консоли можно много чего делать, Ctrl+C нажимать, например. Что должно происходить по всяким таким доп. событиям в доп консоли?
E>Все ли обработчики таких событий в твоей программе и во всех используемых библиотеках будут готовы к таким событиям в побочной консоли?..

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


E>Как совместимый вариант могу предложить написать простое консольное приложение, которое будет из командной строки брать хендел трубы на вход и трубы на выход, и перенаправлять выход на консоль, а ввод с консоли перенаправлять в выходную трубу. Ну и какой-то простой способ завершиться.
E>Ну а с клиентской стороны создавать две трубы наследуемые, использовать их в качестве тех самых потоков, и запускать это приложение с этими трубами в качестве параметров...

У меня была такая мысль — сделать второе приложение, которое будет по TCP общаться с основным приложением, передавать ему команды и выводить в свою консоль ответные сообщения. В основном приложении будет работать класс-наблюдатель, который будет слушать какой-то порт, получая оттуда команды. Это то же самое ?)

Возможно, самое простое решение будет как предложил watchmaker — сделать средствами qt две формы, в одну кидать сообщения-ответы, а в другую писать команду, которую по клацу кнопки на форме отправлять в систему...

Здравствуйте, Кузнец, Вы писали:

К>Возможно, самое простое решение будет как предложил watchmaker — сделать средствами qt две формы, в одну кидать сообщения-ответы, а в другую писать команду, которую по клацу кнопки на форме отправлять в систему...

Можно просто по на сокет вешать слушателя и по telnet'у подключаться...
Будет и стандартно и совместимо и всё такое...

Единственный момент, надо как-то безопасность обеспечить. Ну там включать это дело только в отладочной моде, или разрешать конектиться только локально и т. п...

Здравствуйте, Кузнец, Вы писали:

К>Хочется создать дополнительную консоль, с которой связать потоки ввода и вывода. То есть помимо основной консоли (из которой была запущена программа, и с которой работают stdin и stdout), хочется иметь вторую консоль. Есть ли в c++ подобный функционал? Кроме различных хитростей с qt-шными формами текстового ввода/вывода.

Windows не поддерживает несколько консолей в одном процессе, поэтому по крайней мере под Windows C++ ничем помочь не может

Здравствуйте, Кузнец, Вы писали:

К>Универсальное необязательно (хотя, если оно есть, лучше универсальное, но врятли оно существует). Под Linux Debian нужно.

Варианты:
1. Запустить из-под своей программы xterm/konsole/etc. (можно первое, что из этого найдётся) с указанием конкретной исполняемой программы — коннектора к твоей основной. Потребуется ещё этот коннектор и протокол связи. В качестве коннектора для начала берётся telnet, он даст построчный режим общения.
2. Как в пункте 1, но rbash или аналог с заданием набора допустимых команд. Это если нужно дать удобное редактирование с повторным вызовом из истории.
3. Окно (графическое) со своей эмуляцией терминала. Можно исключить всю специфику ANSI команд, оставив чисто построчный режим, но редактирование будет неудобным.

К>Вообще эта консоль нужна для очень простого функционала — в большом проекте (99% которого пишу не я) работает несколько моих классов, хочется иметь возможность давать им отладочные команды, например в процессе работы запросить состояние, вот я и хотел сделать терминал, который бы общался чисто с этими классами (вернее с одним главным — наблюдателем, который и раздавал бы команды тем, кому они предназначены). Если это совместить с консолью основной программы, то во-первых будет треш из-за смешивания логов разных компонент ПО, во-вторых скорее всего консоль будет ожидать ввода, и этим попросту остановит выполнение программы, что недопустимо.

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

К>У меня была такая мысль — сделать второе приложение, которое будет по TCP общаться с основным приложением, передавать ему команды и выводить в свою консоль ответные сообщения. В основном приложении будет работать класс-наблюдатель, который будет слушать какой-то порт, получая оттуда команды. Это то же самое ?)

Вот я и говорю — такое второе писать не надо, есть готовый и отработанный десятилетиями telnet

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Windows не поддерживает несколько консолей в одном процессе, поэтому по крайней мере под Windows C++ ничем помочь не может

Ну чо за бред то! Сколько угодно их создавай.

Console Functions.

Здравствуйте, Кузнец, Вы писали:

К>Хочется создать дополнительную консоль, с которой связать потоки ввода и вывода.

Windows API, Console Functions. Там примеров тьма.

Здравствуйте, Erop, Вы писали:

E>Можно просто по на сокет вешать слушателя и по telnet'у подключаться...
E>Будет и стандартно и совместимо и всё такое...

E>Единственный момент, надо как-то безопасность обеспечить. Ну там включать это дело только в отладочной моде, или разрешать конектиться только локально и т. п...

Точно, про telnet я знал, но дурацкая привычка изобретать велосипеды чуть не подвела .

По безопасности всё просто — от telnet'а будет получать сообщения конкретный класс, в нём я буду реагировать на ограниченный набор сообщений, поэтому через него попросту нет возможности навредить (как мне кажется, любые нехорошие сообщения не будут распознаны как осмысленные, и класс их просто проигнорирует). Команды будут только запрашивающие состояние, никаких серьёзных данных я пока не собираюсь отдавать.

Ну и конечно же — в крайнем случае этот функционал можно отключить, нужно это только для отладки (хотя на дорелизных версиях ПО всё же хотелось бы эту штуковину иметь, а пререлиз устанавливается на рабочие машины, и работает в реальных условиях, так что если всё же эта схема уязвима, то при выдаче любой версии придётся это всё дело тереть...).

Ещё есть вариант — подключаться по паролю, взять какую-нибудь простую схему с хешами, например Sha-3, она вроде несложная, и использовать её в этом месте. Для подключения нужно будет знать пароль. Sha-3 по-моему не взломана, так что её хватит за глаза. Если подключаться будем только локально, то пароль не перехватят, и по идее всё должно быть хорошо (хотя врятли кому-то так сильно понадобится залезть туда, думаю хватит минимальной защиты от дурака).

Здравствуйте, Мёртвый Даун, Вы писали:

PD>>Windows не поддерживает несколько консолей в одном процессе, поэтому по крайней мере под Windows C++ ничем помочь не может

МД>Ну чо за бред то! Сколько угодно их создавай.

A process can be associated with only one console, so the AllocConsole function fails if the calling process already has a console.

https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms681944(v=vs.85).aspx

Здравствуйте, Кузнец, Вы писали:

К>Ну и конечно же — в крайнем случае этот функционал можно отключить, нужно это только для отладки (хотя на дорелизных версиях ПО всё же хотелось бы эту штуковину иметь, а пререлиз устанавливается на рабочие машины, и работает в реальных условиях, так что если всё же эта схема уязвима, то при выдаче любой версии придётся это всё дело тереть...).

Можно динамически отключать по какому-то условию. Ну, например, иметь список пользователей/машин при запуске с которых можно.

К>Ещё есть вариант — подключаться по паролю, взять какую-нибудь простую схему с хешами, например Sha-3, она вроде несложная, и использовать её в этом месте. Для подключения нужно будет знать пароль. Sha-3 по-моему не взломана, так что её хватит за глаза. Если подключаться будем только локально, то пароль не перехватят, и по идее всё должно быть хорошо (хотя врятли кому-то так сильно понадобится залезть туда, думаю хватит минимальной защиты от дурака).

Ну, например.

Я бу ещё выяснил, а нет ли уже в приложении подобной отладочной инфраструктуры. Может можно просто к ней присоединиться.
Если нет, кстати, то можно сразу написать это в таком виде, что бы твой класс был клиентом, вдруг ещё кому понадобится.

Здравствуйте, Кузнец, Вы писали:

К>Вообще эта консоль нужна для очень простого функционала — в большом проекте (99% которого пишу не я) работает несколько моих классов, хочется иметь возможность давать им отладочные команды, например в процессе работы запросить состояние, вот я и хотел сделать терминал, который бы общался чисто с этими классами (вернее с одним главным — наблюдателем, который и раздавал бы команды тем, кому они предназначены). Если это совместить с консолью основной программы, то во-первых будет треш из-за смешивания логов разных компонент ПО, во-вторых скорее всего консоль будет ожидать ввода, и этим попросту остановит выполнение программы, что недопустимо.
Может правильнее было бы разработать юнит-тесты для данной цели?
Ну или же в процессе работы — ориентироваться по различным лог-ам.

К>У меня была такая мысль — сделать второе приложение, которое будет по TCP общаться с основным приложением, передавать ему команды и выводить в свою консоль ответные сообщения. В основном приложении будет работать класс-наблюдатель, который будет слушать какой-то порт, получая оттуда команды. Это то же самое ?)
ИМХО — усложнение.

К>Возможно, самое простое решение будет как предложил watchmaker — сделать средствами qt две формы, в одну кидать сообщения-ответы, а в другую писать команду, которую по клацу кнопки на форме отправлять в систему...
Тоже вариант.

Здравствуйте, Кузнец, Вы писали:

К>Хочется создать дополнительную консоль, с которой связать потоки ввода и вывода. То есть помимо основной консоли (из которой была запущена программа, и с которой работают stdin и stdout), хочется иметь вторую консоль. Есть ли в c++ подобный функционал? Кроме различных хитростей с qt-шными формами текстового ввода/вывода.

В C++ такого функционала нет, потому что само понятие консоли системно-зависимое. Где-то консоль — это такое окошко на экране, а где-то, электрическая печатная машинка "Консул", присоединенная к компьютеру проводами. Как вы думаете, можно програмно на C++ создать печатную машинку "Консул"?

Там, где консоль является програмно-создаваемым объектом, есть соответствующий системный API, который можно вызвать из программы на C++.

Здравствуйте, Кузнец, Вы писали:

К>Хочется создать дополнительную консоль, с которой связать потоки ввода и вывода.

Может и не в тему, но есть такой класс QProcess.