filesystem/path behavior
Hi, I was trying to use the boost::filesystem::path class (from boost_1_33_1) and surprisingly, the following little piece of code just asserts: /* g++ -v -I${HOME}/installed/local/include -L${HOME}/installed/local/ lib \ -o boost boost.cc -lboost_filesystem */ #include <boost/filesystem/path.hpp> int main( int argc, char *argv[] ) { boost::filesystem::path p("/usr/include/c++/4.0.0/cstring"); return 0; } Bahia:bugs$ ./boost terminate called after throwing an instance of 'boost::filesystem::filesystem_error' what(): boost::filesystem::path: invalid name "c++" in path: "/ usr/include/c++/4.0.0/cstring" Abort trap Bahia:bugs$ Is there any reason why I couldn't construct a path like this? I was just trying to access a file in the default include directory of the gcc install on Mac OSX 10.4. Thank you, Sebastien.
Sebastien Mirolo wrote:
terminate called after throwing an instance of 'boost::filesystem::filesystem_error' what(): boost::filesystem::path: invalid name "c++" in path: "/ usr/include/c++/4.0.0/cstring"
See http://boost.org/libs/filesystem/doc/path.htm#constructors and http://boost.org/libs/filesystem/doc/portability_guide.htm HTH, m Send instant messages to your online friends http://au.messenger.yahoo.com
Martin Wille <mw8329@yahoo.com.au> wrote:
Sebastien Mirolo wrote:
terminate called after throwing an instance of 'boost::filesystem::filesystem_error' what(): boost::filesystem::path: invalid name "c++" in path: "/ usr/include/c++/4.0.0/cstring"
See http://boost.org/libs/filesystem/doc/path.htm#constructors and http://boost.org/libs/filesystem/doc/portability_guide.htm
Having been a user of filesystem for quite a while, I really think it is time to turn off any default checking. This is hardly the first time that we have seen this kind of non-error cause a problem. Cheers, Walter Landry wlandry@ucsd.edu
Walter Landry wrote:
Martin Wille wrote:
See http://boost.org/libs/filesystem/doc/path.htm#constructors and http://boost.org/libs/filesystem/doc/portability_guide.htm
Having been a user of filesystem for quite a while, I really think it is time to turn off any default checking. This is hardly the first time that we have seen this kind of non-error cause a problem.
I see two other possible improvements: 1. remove the default, requiring the user always to pass a checker. This will definitely stop the guessing among the users. 2. make the error message contain a hint that the default checker might be the wrong choice. Regards, m Send instant messages to your online friends http://au.messenger.yahoo.com
Thanks. That really helps to understand what is going on. I think number 1 is better because you don't end-up testing your system and then it breaks as soon as it hits the customer site. I would actually like #3 too: using the native name_checker as default. Still number 1 seems the best alternative to build reliable software. Sebastien. On Apr 18, 2006, at 5:20 AM, Martin Wille wrote:
Walter Landry wrote:
Martin Wille wrote:
See http://boost.org/libs/filesystem/doc/path.htm#constructors and http://boost.org/libs/filesystem/doc/portability_guide.htm
Having been a user of filesystem for quite a while, I really think it is time to turn off any default checking. This is hardly the first time that we have seen this kind of non-error cause a problem.
I see two other possible improvements:
1. remove the default, requiring the user always to pass a checker. This will definitely stop the guessing among the users.
2. make the error message contain a hint that the default checker might be the wrong choice.
Regards, m Send instant messages to your online friends http:// au.messenger.yahoo.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost
Martin Wille <mw8329@yahoo.com.au> wrote:
Walter Landry wrote:
Martin Wille wrote:
See http://boost.org/libs/filesystem/doc/path.htm#constructors and http://boost.org/libs/filesystem/doc/portability_guide.htm
Having been a user of filesystem for quite a while, I really think it is time to turn off any default checking. This is hardly the first time that we have seen this kind of non-error cause a problem.
I see two other possible improvements:
1. remove the default, requiring the user always to pass a checker. This will definitely stop the guessing among the users.
2. make the error message contain a hint that the default checker might be the wrong choice.
Both of these options make the user learn about things that they should not have to learn about. Just get rid of default checking. If people want to ensure that all paths that pass through their program will be valid on some arbitrary set of filesystems, then they can set that themselves. The filesystem library should not be my nanny. Cheers, Walter Landry wlandry@ucsd.edu
On 4/19/06, Walter Landry <wlandry@ucsd.edu> wrote:
Both of these options make the user learn about things that they should not have to learn about. Just get rid of default checking. If people want to ensure that all paths that pass through their program will be valid on some arbitrary set of filesystems, then they can set that themselves. The filesystem library should not be my nanny.
The library, however, /should/ make the default thing the right thing, as it does now. I think a better option would be to add " If you don't know why this path is invalid, read http://boost.org/libs/filesystem/doc/portability_guide.htm#name_check%AD_fun... " to the exception's .what() message in debug mode. ~ SWMc
me22 <me22.ca@gmail.com> wrote:
On 4/19/06, Walter Landry <wlandry@ucsd.edu> wrote:
Both of these options make the user learn about things that they should not have to learn about. Just get rid of default checking. If people want to ensure that all paths that pass through their program will be valid on some arbitrary set of filesystems, then they can set that themselves. The filesystem library should not be my nanny.
The library, however, /should/ make the default thing the right thing, as it does now.
It is _not_ doing the right thing. It is giving errors for valid paths. It adds complexity to codes that don't need it. The code that started this thread should have worked.
I think a better option would be to add " If you don't know why this path is invalid, read http://boost.org/libs/filesystem/doc/portability_guide.htm#name_check%AD_fun... " to the exception's .what() message in debug mode.
This still makes people learn about path checking when they should not have to. Don't make me think. Cheers, Walter Landry wlandry@ucsd.edu
Walter Landry <wlandry@ucsd.edu> writes:
me22 <me22.ca@gmail.com> wrote:
On 4/19/06, Walter Landry <wlandry@ucsd.edu> wrote:
Both of these options make the user learn about things that they should not have to learn about. Just get rid of default checking. If people want to ensure that all paths that pass through their program will be valid on some arbitrary set of filesystems, then they can set that themselves. The filesystem library should not be my nanny.
The library, however, /should/ make the default thing the right thing, as it does now.
It is _not_ doing the right thing. It is giving errors for valid paths. It adds complexity to codes that don't need it. The code that started this thread should have worked.
I think a better option would be to add " If you don't know why this path is invalid, read http://boost.org/libs/filesystem/doc/portability_guide.htm#name_check%AD_fun... " to the exception's .what() message in debug mode.
This still makes people learn about path checking when they should not have to. Don't make me think.
100% agreed. If the filesystem library is going to be useful for operating on real filesystems, it has to operate on real paths without making the programmer jump through hoops. The reality is that the actual paths we need to deal with are in general _not_ portable across all systems, and 99% of them are dictated by existing constraints of the filesystem or installed software and data, rather than being conjured from whole cloth by C++ programmers using the filesystem library. Taking out this checking is long overdue. If it were a compile-time check, I'd find it annoying and limiting -- which is bad enough -- but the fact that it's a runtime check makes it error-prone and likely to fail at the worst time. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Walter Landry" <wlandry@ucsd.edu> wrote in message news:20060418.023941.104030760.walter@geodynamics.org...
Martin Wille <mw8329@yahoo.com.au> wrote:
Sebastien Mirolo wrote:
terminate called after throwing an instance of 'boost::filesystem::filesystem_error' what(): boost::filesystem::path: invalid name "c++" in path: "/ usr/include/c++/4.0.0/cstring"
See http://boost.org/libs/filesystem/doc/path.htm#constructors and http://boost.org/libs/filesystem/doc/portability_guide.htm
Having been a user of filesystem for quite a while, I really think it is time to turn off any default checking. This is hardly the first time that we have seen this kind of non-error cause a problem.
The checking mechanism was removed for 1.34. The change was made as part of the i18n changes last year, but it just missed the 1.33 release, so has been awaiting the 1.34 release since then. We really need to rethink the release process. There needs to be a way to easily update just a single library, and for users to easily get that update. --Beman
Beman Dawes wrote:
We really need to rethink the release process. There needs to be a way to easily update just a single library, and for users to easily get that update.
Not disagreeing, but until such time there is always the File Vault. Bundle your latest version into a zip, test it with a few older versions of Boost and upload it. And maintain it. :-) -- Eric Niebler Boost Consulting www.boost-consulting.com
"Beman Dawes" <bdawes@acm.org> writes:
"Walter Landry" <wlandry@ucsd.edu> wrote in message news:20060418.023941.104030760.walter@geodynamics.org...
Martin Wille <mw8329@yahoo.com.au> wrote:
Sebastien Mirolo wrote:
terminate called after throwing an instance of 'boost::filesystem::filesystem_error' what(): boost::filesystem::path: invalid name "c++" in path: "/ usr/include/c++/4.0.0/cstring"
See http://boost.org/libs/filesystem/doc/path.htm#constructors and http://boost.org/libs/filesystem/doc/portability_guide.htm
Having been a user of filesystem for quite a while, I really think it is time to turn off any default checking. This is hardly the first time that we have seen this kind of non-error cause a problem.
The checking mechanism was removed for 1.34.
In that case, I apologize for my screed. :( -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (7)
-
Beman Dawes -
David Abrahams -
Eric Niebler -
Martin Wille -
me22 -
Sebastien Mirolo -
Walter Landry