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