| [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 automatic 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] |