(Using namespace boost::wave here on.)
It seems that util::file_position<> has an assertion that checks if a given filename contains any following sequences: <\\>, <\"> or <\?> (using util::debug::is_escaped_lit).
I wonder why file_position<> does need to check this and if it's so crucial why it's done using a mere BOOST_ASSERT?
Now, here's comes the reason why I'm asking this: At least with MSVC9's remote debugger (or some other lowlevel component; not really the interesting part here) translates all network shares on a remote computer to UNC-paths. This is correct behaviour and actually a very neat feature. However, as you might be already aware at this point this leads to the actual problem: Any UNC-path triggers (consider <\\foo\path\file>) the assertion and things go boom.
It is not possible to easily work around this by refactoring user code and/or input values as provided filenames are completed internally using util::complete_path (after which <file> becomes <\\foo\path\file> etc. in this case).
I tried to disable this assertion (actually, there's two; one in the constructor and one in the set_file member function) and didn't see any strange behaviour. E.g. std::ifstream handling with UNC-paths in iteration_context_policies::load_file_to_string::inner<> worked just fine, as expected from a native STL.
Goes without saying that I'm using the latest Boost version (1.47.0). I would be very pleased if anyone could shed some light on this matter or better still - fix it permanently.
Right, that's apparently a leftover from old boost.filesystem times, when it did not support UNC paths. I'll remove the checks asap. Regards Hartmut --------------- http://boost-spirit.com