On 10/27/06, Jeff F
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; }