As already reported in http://article.gmane.org/gmane.comp.lib.boost.devel/128277, narrow_path() doesn't work if short filename generation is disabled. As a workaround I have fstream.hpp patched for using the non-standard wide char fstream constructors in VC8 (Dinkumware library). Indeed this works for VC8 only...
Would you like to contribute your patch? That might be faster and easier than waiting for me to get around to it!
Shure. Patch against current CVS attached.
Ok, I have seen the free function what() but what it's the rationale not including it in the exception object?
The what() free function provides more elaborate formatting. The member what() function is minimal, and so doesn't have as many memory allocation issues. The approach is take to follow the guidelines at www.boost.org/more/error_handling.html.
I see. It's a pity, it would be fine to have m_path1 and m_path2 provided by the what() member... Cheers, Jan
"Jan Hermelink" <Jan.Hermelink@metalogic.de> wrote in message news:EB650214CCEA984983BC694221A6D3BF06D727@JUPITER.muenchen.metalogic.de...
As already reported in http://article.gmane.org/gmane.comp.lib.boost.devel/128277, narrow_path() doesn't work if short filename generation is disabled. As a workaround I have fstream.hpp patched for using the non-standard wide char fstream constructors in VC8 (Dinkumware library). Indeed this works for VC8 only...
Would you like to contribute your patch? That might be faster and easier than waiting for me to get around to it!
Shure. Patch against current CVS attached.
OK, thanks! I reworked it a bit to test for Dinkumware version 405, as the fix is really library specific rather than compiler specific. That's important as Intel, among others, also uses that library. There was also an issue with filebuf, which is also hopefully fixed, and I renamed the function since it no longer always returns a narrow path. --Beman
participants (2)
-
Beman Dawes -
Jan Hermelink