On 10/27/06, Jeff F <TriumphSprint2000@hotmail.com> wrote:
Is this v1.33.0 or v1.33.1? Have you tried: catch ( const std::exception& e)?
 
What compiler? version? ...

Can you supply a complete minimal source code example that demonstrates the problem?

You're right: I have failed to produce enough information to resolve the issue at hand.  I am running Windows 2003 Server, VS 2005 (version 8.0), Intel Compiler 9.1 with Boost version 1.33.0.  I am using the intel compiler to build boost and I use it to build my project in visual studio.

I have come to some semblance of a conclusion: I'm linking against the wrong library.  Linking against the production library (boost_filesystem-mt.lib) when building the project in debug mode causes this behavior.  When linking against the debug library (boost_filesystem- mt-gd.lib) the issue is no longer present.

I've included a complete source file which exhibits this behavior.  When linked against the release lib in debug mode, an access violation occurs when the tmp_path.string() method is called on line 16.  I've never seen behavior like this on linux or Mac OS X.

--- test.cpp ---
#include <iostream>
#include <string>
#include <cstdlib>

#include "boost/filesystem/path.hpp"
#include "boost/filesystem/exception.hpp"
#include "boost/filesystem/operations.hpp"

using boost::filesystem::path;

int main (int argc, char ** argv)
{
    try
    {
        path tmp_path ("tmp", boost::filesystem::native);
        std::cout << "process path: " << tmp_path.string () << std::endl;
    }
    catch (boost::filesystem::filesystem_error & e)
    {
        std::cerr << "filesystem_error exception thrown!" << std::endl;
    }
    catch (...)
    {
        std::cerr << "an exception was thrown!" << std::endl;
    }

    return 0;
}