他のプログラムを変更することなく、別の C++ プログラムにデータを送信することは可能ですか? もしそうなら、どのようにしますか?私の現在の方法では、一時ファイルを作成し、ファイル名をパラメーターとして他のプログラムを起動します。唯一の問題は、後でクリーンアップするために大量の一時ファイルが残されることです。これは望ましくありません。
編集:また、ブーストはオプションではありません。
他のプログラムを変更することなく、別の C++ プログラムにデータを送信することは可能ですか? もしそうなら、どのようにしますか?私の現在の方法では、一時ファイルを作成し、ファイル名をパラメーターとして他のプログラムを起動します。唯一の問題は、後でクリーンアップするために大量の一時ファイルが残されることです。これは望ましくありません。
編集:また、ブーストはオプションではありません。
明らかに、2 番目のプログラムがサポートしている場合は、stdin へのパイプを作成するのがよい方法です。フレッドがコメントで述べたように、名前付きファイルが提供されていない場合、または-
ファイル名として使用されている場合、多くのプログラムは stdin を読み取ります。
ファイル名が必要で、Linux を使用している場合は、これを試してください: パイプを作成し、コマンド ラインで/dev/fd/<fd-number>
orを渡します。/proc/self/fd/<fd-number>
例として、これが hello-world 2.0 です。
#include <string>
#include <sstream>
#include <cstdlib>
#include <cstdio>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
int main () {
int pfd[2];
int rc;
if( pipe(pfd) < 0 ) {
perror("pipe");
return 1;
}
switch(fork()) {
case -1: // Error
perror("fork");
return 1;
case 0: { // Child
// Close the writing end of the pipe
close(pfd[1]);
// Create a filename that refers to reading end of pipe
std::ostringstream path;
path << "/proc/self/fd/" << pfd[0];
// Invoke the subject program. "cat" will do nicely.
execlp("/bin/cat", "cat", path.str().c_str(), (char*)0);
// If we got here, then something went wrong, then execlp failed
perror("exec");
return 1;
}
default: // Parent
// Close the reading end.
close(pfd[0]);
// Write to the pipe. Since "cat" is on the other end, expect to
// see "Hello, world" on your screen.
if (write(pfd[1], "Hello, world\n", 13) != 13)
perror("write");
// Signal "cat" that we are done writing
close(pfd[1]);
// Wait for "cat" to finish its business
if( wait(0) < 0)
perror("wait");
// Everything's okay
return 0;
}
}
You could use sockets. It sounds like both application are on the same host, so you just identify the peers as localhost:portA and localhost:port B. And if you do it this way you can eventually graduate to do network IO. No temp files, no mystery parse errors or file deletions. TCP guarantees packet delivery and guarantees they will be ordered correctly.
So yeah, I would consider creating an synchronous socket server (use asynchronous if you anticipate having tons of peers). One benefit over pipe oriented IPC is that TCP sockets are completely universal. Piping varies dramatically based upon what system you are on (consider Windows named pipes vs implicit and explicit POSIX pipes -> very different).