87 lines
2.4 KiB
Plaintext
87 lines
2.4 KiB
Plaintext
[section:faq Frequently Asked Questions]
|
|
|
|
[section:dead_lock Why does this produce a deadlock?]
|
|
|
|
Now let's revisit our c++filt example and we will put in an obvious mistake.
|
|
This might however be not as obvious for more complex applications.
|
|
|
|
```
|
|
vector<string> demangle(vector<string> in)
|
|
{
|
|
|
|
ipstream is;
|
|
opstream os;
|
|
child c("c++filt", std_out > is, std_in < os);
|
|
|
|
vector<string> data;
|
|
for (auto & elem : data)
|
|
{
|
|
string line;
|
|
getline(is, line);
|
|
os << elem;
|
|
}
|
|
}
|
|
|
|
```
|
|
We switched the read and write operation up, so that's causing a dead-lock.
|
|
This locks immediately. This is because `c++filt` expects input, before
|
|
outputting any data. The launching process on the other hand waits for its output.
|
|
|
|
[endsect]
|
|
|
|
[section:closep Why does the pipe not close?]
|
|
|
|
Now for another example, which might look correct, let's consider you want
|
|
to use `ls` to read the current directory.
|
|
|
|
```
|
|
ipstream is;
|
|
child c("ls", std_out > is);
|
|
|
|
std::string file;
|
|
while (is >> file)
|
|
cout << "File: " << file << endl;
|
|
|
|
```
|
|
|
|
This will also deadlock, because the pipe does not close when the subprocess exits.
|
|
So the `ipstream` will still look for data even though the process has ended.
|
|
|
|
[note It is not possible to use automatically pipe-closing in this library, because
|
|
a pipe might be a file-handle (as for async pipes on windows).]
|
|
|
|
But, since pipes are buffered, you might get incomplete data if you do this:
|
|
|
|
```
|
|
ipstream is;
|
|
child c("ls", std_out > is);
|
|
|
|
std::string file;
|
|
while (c.running())
|
|
{
|
|
is >> file;
|
|
cout << "File: " << file << endl;
|
|
}
|
|
```
|
|
|
|
It is therefore highly recommended that you use the asynchronous api if you are
|
|
not absolutely sure how the output will look.
|
|
|
|
[endsect]
|
|
|
|
[section:wchar_t When will the codecvt be used?]
|
|
|
|
Since windows does not use UTF-8 it is sometimes unavoidable to use the `wchar_t` version of the WinApi.
|
|
To keep this library consistent it provides `wchar_t` support on posix also.
|
|
|
|
Since the posix api is purely `char` every `wchar_t` based type will be converted into `char`.
|
|
|
|
Windows on the other hand is more selective; the default is to use `char`,
|
|
but if any parameter requires `wchar_t`, everything will be converted to `wchar_t`.
|
|
This also includes `boost::filesystem::path`. Additionally, if the system does not provide
|
|
the `char` api (as is the case with Windows CE) everything will also be converted.
|
|
|
|
|
|
[endsect]
|
|
|
|
[endsect] |