Boost C++ Libraries

...one of the most highly regarded and expertly designed C++ library projects in the world. Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

This is the documentation for an old version of Boost. Click here to view this page for the latest version.
PrevUpHomeNext

Frequently Asked Questions

Why does this produce a deadlock?
Why does the pipe not close?
When will the codecvt be used?

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.

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

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.


PrevUpHomeNext