| Home | Libraries | People | FAQ | More

## Frequently Asked Questions

### 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.

### 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.

### 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.