A few months ago I started to write my first multi-platform application.
In the hope to be shielded from all kinds of filesystem specific issues,
I started to use boost - also for the first time - mainly because of
of boost::filesystem.
However - I have found that it doesn't shield me from a LOT of filesystem
specific things. In the meantime I was in the need of writing six additional
functions that are filesystem specific:
std::string native_file_string(fs::path const&);
void copy_file(fs::path const& source_file, fs::path const& target_file);
void chmod(fs::path const& filename, bool readonly);
bool is_readonly(fs::path const& filename);
void rename_file(fs::path const& source_file, fs::path const& target_file);
size_t get_file_size(fs::path const& filename);
Today I ran into a very serious problem. Hopefully it is just me who
is making a stupid mistake (however unlikely that may sound ;) but it sure
seems like a huge bug in boost::filesystem of a magnitude that not only amazes
me but will also force me to stop using boost::filesystem if this is true.
The reason that I didn't find this problem earlier in the pasts months
is because so far I've done all development on GNU/Linux - and only recently
have started to actually try and get things to work on cygwin.
The reason I subscribed to this list is in the hope to find Beman here,
is he reading this list? My hope is to start a public discussion about
boost::filesystem - problems, improvements, missing features etc.
I will sent a separate mail for the 'serious bug' that I just mentioned,
because it isn't 100% sure yet that this is actually a bug ;).
--
Carlo Wood
Carlo Wood wrote:
The reason I subscribed to this list is in the hope to find Beman here, is he reading this list? My hope is to start a public discussion about boost::filesystem - problems, improvements, missing features etc.
Unfortunatelly, Beman is offline for some time already (we are missing him, too). However, there are other Boost developers list on this list. B.
Hi Carlo, I just wanted to point out native_file_string is part of boost::filesystem::path and copy_file and rename_file (actually called rename) are part of boost::filesystem (operations.hpp). As far as file size I think you can get it from the stream. -delfin
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Carlo Wood Sent: Tuesday, August 17, 2004 5:53 AM To: boost-users@lists.boost.org Subject: [Boost-users] boost::filesystem problems
A few months ago I started to write my first multi-platform application. In the hope to be shielded from all kinds of filesystem specific issues, I started to use boost - also for the first time - mainly because of of boost::filesystem.
However - I have found that it doesn't shield me from a LOT of filesystem specific things. In the meantime I was in the need of writing six additional functions that are filesystem specific:
std::string native_file_string(fs::path const&); void copy_file(fs::path const& source_file, fs::path const& target_file); void chmod(fs::path const& filename, bool readonly); bool is_readonly(fs::path const& filename); void rename_file(fs::path const& source_file, fs::path const& target_file); size_t get_file_size(fs::path const& filename);
Today I ran into a very serious problem. Hopefully it is just me who is making a stupid mistake (however unlikely that may sound ;) but it sure seems like a huge bug in boost::filesystem of a magnitude that not only amazes me but will also force me to stop using boost::filesystem if this is true.
The reason that I didn't find this problem earlier in the pasts months is because so far I've done all development on GNU/Linux - and only recently have started to actually try and get things to work on cygwin.
The reason I subscribed to this list is in the hope to find Beman here, is he reading this list? My hope is to start a public discussion about boost::filesystem - problems, improvements, missing features etc.
I will sent a separate mail for the 'serious bug' that I just mentioned, because it isn't 100% sure yet that this is actually a bug ;).
-- Carlo Wood
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
"Delfin Rojas"
Hi Carlo,
I just wanted to point out native_file_string is part of boost::filesystem::path and copy_file and rename_file (actually called rename) are part of boost::filesystem (operations.hpp).
As far as file size I think you can get it from the stream.
Yes, but std::streamoff is not guaranteed to be large enough to hold the size of really huge files. operations.hpp in the current CVS contains this: boost::intmax_t file_size( const path & ph ); Jonathan
At Tuesday 2004-08-17 15:14, you wrote:
"Delfin Rojas"
wrote in message news:200408172140.i7HLeBjj028031@patti.moodlogic.com... Hi Carlo,
I just wanted to point out native_file_string is part of boost::filesystem::path and copy_file and rename_file (actually called rename) are part of boost::filesystem (operations.hpp).
As far as file size I think you can get it from the stream.
Yes, but std::streamoff is not guaranteed to be large enough to hold the size of really huge files.
really? how'd the committee manage to mess that one up? or are you saying some implementations are deficient in their specification of std::streamoff?
operations.hpp in the current CVS contains this:
boost::intmax_t file_size( const path & ph );
Jonathan
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
"Victor A. Wagner Jr."
At Tuesday 2004-08-17 15:14, you wrote:
"Delfin Rojas"
wrote in message
As far as file size I think you can get it from the stream.
Yes, but std::streamoff is not guaranteed to be large enough to hold the size of really huge files.
really? how'd the committee manage to mess that one up? or are you saying some implementations are deficient in their specification of std::streamoff?
It's typical for streamoff to be an alias for a 32-bit long. Currently there's no type the committee could have specified which would cover the full range of file sizes commonly supported by OS's. Jonathan
On Tue, Aug 17, 2004 at 02:40:14PM -0700, Delfin Rojas wrote:
Hi Carlo,
I just wanted to point out native_file_string is part of boost::filesystem::path and copy_file and rename_file (actually called rename) are part of boost::filesystem (operations.hpp).
I am aware of that. The point is that I had a need to rewrite them.
That seems to indicate that the boost implementation is flawed.
--
Carlo Wood
At Tuesday 2004-08-17 17:16, you wrote:
On Tue, Aug 17, 2004 at 02:40:14PM -0700, Delfin Rojas wrote:
Hi Carlo,
I just wanted to point out native_file_string is part of boost::filesystem::path and copy_file and rename_file (actually called rename) are part of boost::filesystem (operations.hpp).
I am aware of that. The point is that I had a need to rewrite them. That seems to indicate that the boost implementation is flawed.
perhaps you could enlighten us further? "doesn't work" is a lousy bug report "flawed" isn't a lot better.
-- Carlo Wood
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
On Tue, Aug 17, 2004 at 11:55:22PM -0700, Victor A. Wagner Jr. wrote:
At Tuesday 2004-08-17 17:16, you wrote:
On Tue, Aug 17, 2004 at 02:40:14PM -0700, Delfin Rojas wrote:
Hi Carlo,
I just wanted to point out native_file_string is part of boost::filesystem::path and copy_file and rename_file (actually called rename) are part of boost::filesystem (operations.hpp).
I am aware of that. The point is that I had a need to rewrite them. That seems to indicate that the boost implementation is flawed.
perhaps you could enlighten us further? "doesn't work" is a lousy bug report "flawed" isn't a lot better.
My problem is that Beman is not here. It seems to make little
sense to try to convince people when in the end nobody is going
to make changes to boost when he is not here.
But I can tell you what I improved of course. Lets start with
just one case.
boost::filesystem::copy_file starts with truncating the target
file - and when an error occurs, it throws - but STILL did truncate
the target file (assuming it already existed) (the exception at
the bottom of the function).
This is not how I want exceptions to work; when an exception is
thrown from a function then nothing must have been changed - as
if the exception is thrown at the start of the function.
My implementation of copy_file either succeeds completely or doesn't
do anything: it is atomic.
I need this for robustness. I don't write applications that '"Oops"
some error occured - sorry, your configuration file was erased - no
there is no backup, I was trying to make one namely'. I have a gard my
reputation to write robust and bug free code ;).
The other changes are mostly also related to the need for a better
defined post-condition in case of errors.
--
Carlo Wood
Adding exception safety in the "succeeds or has no effect" to copy_file certainly seem like reasonable suggestion. It adds a small complication of creating a temporary file first, but I'd say it was generally worth it. Note that _could_ change the behavior of some programs that are correctly functioning now in very limited "file space" and make them inoperative. At Wednesday 2004-08-18 05:19, you wrote:
On Tue, Aug 17, 2004 at 11:55:22PM -0700, Victor A. Wagner Jr. wrote:
At Tuesday 2004-08-17 17:16, you wrote:
On Tue, Aug 17, 2004 at 02:40:14PM -0700, Delfin Rojas wrote:
Hi Carlo,
I just wanted to point out native_file_string is part of boost::filesystem::path and copy_file and rename_file (actually called rename) are part of boost::filesystem (operations.hpp).
I am aware of that. The point is that I had a need to rewrite them. That seems to indicate that the boost implementation is flawed.
perhaps you could enlighten us further? "doesn't work" is a lousy bug report "flawed" isn't a lot better.
My problem is that Beman is not here. It seems to make little sense to try to convince people when in the end nobody is going to make changes to boost when he is not here.
But I can tell you what I improved of course. Lets start with just one case.
boost::filesystem::copy_file starts with truncating the target file - and when an error occurs, it throws - but STILL did truncate the target file (assuming it already existed) (the exception at the bottom of the function).
This is not how I want exceptions to work; when an exception is thrown from a function then nothing must have been changed - as if the exception is thrown at the start of the function.
My implementation of copy_file either succeeds completely or doesn't do anything: it is atomic.
I need this for robustness. I don't write applications that '"Oops" some error occured - sorry, your configuration file was erased - no there is no backup, I was trying to make one namely'. I have a gard my reputation to write robust and bug free code ;).
The other changes are mostly also related to the need for a better defined post-condition in case of errors.
-- Carlo Wood
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
So just add a new function (or a parameter to the old function) that doesn't guarantee the "succeeds or has no effect" rule. Alternately you could make the new behavior have the new name but it seems like you want the "default/standard" version to have the guarantee. On Aug 18, 2004, at 7:31 AM, Victor A. Wagner Jr. wrote:
Adding exception safety in the "succeeds or has no effect" to copy_file certainly seem like reasonable suggestion. It adds a small complication of creating a temporary file first, but I'd say it was generally worth it. Note that _could_ change the behavior of some programs that are correctly functioning now in very limited "file space" and make them inoperative.
At Wednesday 2004-08-18 05:19, you wrote:
At Tuesday 2004-08-17 17:16, you wrote:
On Tue, Aug 17, 2004 at 02:40:14PM -0700, Delfin Rojas wrote:
Hi Carlo,
I just wanted to point out native_file_string is part of boost::filesystem::path and copy_file and rename_file (actually called rename) are part of boost::filesystem (operations.hpp).
I am aware of that. The point is that I had a need to rewrite
On Tue, Aug 17, 2004 at 11:55:22PM -0700, Victor A. Wagner Jr. wrote: them.
That seems to indicate that the boost implementation is flawed.
perhaps you could enlighten us further? "doesn't work" is a lousy bug report "flawed" isn't a lot better.
My problem is that Beman is not here. It seems to make little sense to try to convince people when in the end nobody is going to make changes to boost when he is not here.
But I can tell you what I improved of course. Lets start with just one case.
boost::filesystem::copy_file starts with truncating the target file - and when an error occurs, it throws - but STILL did truncate the target file (assuming it already existed) (the exception at the bottom of the function).
This is not how I want exceptions to work; when an exception is thrown from a function then nothing must have been changed - as if the exception is thrown at the start of the function.
My implementation of copy_file either succeeds completely or doesn't do anything: it is atomic.
I need this for robustness. I don't write applications that '"Oops" some error occured - sorry, your configuration file was erased - no there is no backup, I was trying to make one namely'. I have a gard my reputation to write robust and bug free code ;).
The other changes are mostly also related to the need for a better defined post-condition in case of errors.
-- Carlo Wood
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law" _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Carlo Wood
On Tue, Aug 17, 2004 at 11:55:22PM -0700, Victor A. Wagner Jr. wrote:
At Tuesday 2004-08-17 17:16, you wrote:
On Tue, Aug 17, 2004 at 02:40:14PM -0700, Delfin Rojas wrote:
Hi Carlo,
I just wanted to point out native_file_string is part of boost::filesystem::path and copy_file and rename_file (actually called rename) are part of boost::filesystem (operations.hpp).
I am aware of that. The point is that I had a need to rewrite them. That seems to indicate that the boost implementation is flawed.
perhaps you could enlighten us further? "doesn't work" is a lousy bug report "flawed" isn't a lot better.
My problem is that Beman is not here. It seems to make little sense to try to convince people when in the end nobody is going to make changes to boost when he is not here.
I'm discussing with Beman the possibility of appointing an interim maintainer for the library. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
A few months ago I started to write my first multi-platform application. In the hope to be shielded from all kinds of filesystem specific issues, I started to use boost - also for the first time - mainly because of of boost::filesystem.
Interesting to hear from someone who is actually using the boost::filesystem for multi-platform. Personally I have never really understod the reasoning behind the "portability" philosophy behind boost::filesystem. Portability for me means that the code will compile and work the same on different platforms. Strangly enough boost::filesystem works activly against this by enforcing that you use "portable" filenames (unless you specificly turn it off). For me, filenames are input to the application, not a result of it! Why would I want to force a windows user to only enter filenames that are portable?
From a user perspective native_file_string() is portable while string() isn't since it doesn't present the path in a way that the user recognize.
Same thing with wide-character filenames. Why should boost::filesystem::path care if the path it carries is in a std::string or std::wstring? The wide- character filesystem operations can be difficult/impossible to implement on some systems but so are probably other operations. The alternative today is to not use boost::filesystem at all. Don't get me wrong here. I use boost::filesystem in all my applications and I am really happy with it but I also struggle with its limitations. Without wide- character support I probably have to stop using it in a not to distant future.
However - I have found that it doesn't shield me from a LOT of filesystem specific things. In the meantime I was in the need of writing six additional functions that are filesystem specific:
std::string native_file_string(fs::path const&); void copy_file(fs::path const& source_file, fs::path const& target_file); void chmod(fs::path const& filename, bool readonly); bool is_readonly(fs::path const& filename); void rename_file(fs::path const& source_file, fs::path const& target_file); size_t get_file_size(fs::path const& filename);
Add to that the possibility to only iterate over specific files like "*.txt". Only the filsystem knows if "file.TXT" matches "*.txt" so the directory_iterator can't be used for this simple case
Martin wrote:
Add to that the possibility to only iterate over specific files like "*.txt". Only the filsystem knows if "file.TXT" matches "*.txt" so the directory_iterator can't be used for this simple case
You might look at Richard Johnson's glob.hpp. http://aspn.activestate.com/ASPN/Mail/Message/1977422 The OP uploaded the code to http://groups.yahoo.com/group/boost/files/globiter.zip HTH, Angus
On Wed, 18 Aug 2004 10:12:36 +0000 (UTC), Martin wrote
A few months ago I started to write my first multi-platform application. In the hope to be shielded from all kinds of filesystem specific issues, I started to use boost - also for the first time - mainly because of of boost::filesystem.
Interesting to hear from someone who is actually using the boost::filesystem for multi-platform.
Personally I have never really understod the reasoning behind the "portability" philosophy behind boost::filesystem.
Portability for me means that the code will compile and work the same on different platforms.
And it does, unless you specifically make use of platform native features by choice. This argument doesn't make sense to me?
Strangly enough boost::filesystem works activly against this by enforcing that you use "portable" filenames (unless you specificly turn it off).
Exactly. In many cases, making a completely portable application goes beyond compilation and includes the form of the data -- namely the file paths. There are many applications where the developer wants to ensure that the paths will work on all platforms without having to actually test on them.
For me, filenames are input to the application, not a result of it!
That's fine.
Why would I want to force a windows user to only enter filenames that are portable?
That works for your application, but not for others. You are taking user input and want native paths. I think this option is clearly documented in the library.
From a user perspective native_file_string() is portable while string() isn't since it doesn't present the path in a way that the user recognize.
Perhaps they need to be educated ;-)
Same thing with wide-character filenames. Why should boost::filesystem::path care if the path it carries is in a std::string or std::wstring? The wide- character filesystem operations can be difficult/impossible to implement on some systems but so are probably other operations. The alternative today is to not use boost::filesystem at all.
This is simply a question of timing. Beman had been working on a wide string extension for the library. I don't know where it stands, but clearly his intent is to add this capability. My understanding is he is recovering from an illness and is not following the list at the moment.
However - I have found that it doesn't shield me from a LOT of filesystem specific things. In the meantime I was in the need of writing six additional functions that are filesystem specific:
std::string native_file_string(fs::path const&); void copy_file(fs::path const& source_file, fs::path const& target_file); void chmod(fs::path const& filename, bool readonly); bool is_readonly(fs::path const& filename); void rename_file(fs::path const& source_file, fs::path const& target_file); size_t get_file_size(fs::path const& filename);
Can you contribute these? These seem like they would be nice additions to the 'convience' header.
Add to that the possibility to only iterate over specific files like "*.txt". Only the filsystem knows if "file.TXT" matches "*.txt" so the directory_iterator can't be used for this simple case
Search the developer mailing list for 'globbing iterator' and you should find links to a package that does this. It's not officially part of boost, but I think the author was planning on trying to include it. HTH, Jeff
Strangly enough boost::filesystem works activly against this by enforcing that you use "portable" filenames (unless you specificly turn it off).
Exactly. In many cases, making a completely portable application goes beyond compilation and includes the form of the data -- namely the file paths. There are many applications where the developer wants to ensure that the paths will work on all platforms without having to actually test on them.
Can you give an example of such an application because I have difficult to picture an application that will on purpose not accept all paths that are valid on the operating system where it runs. The only use I can see is that you at run-time can ensure that some application generated paths (e.g. path(root / "mysubdir")) are portable but why base an entire library on such a small thing.
Why would I want to force a windows user to only enter filenames that are portable?
That works for your application, but not for others. You are taking user input and want native paths. I think this option is clearly documented in the library.
as above. Why would an application work with paths that don't come from user input or a configuration file.
From a user perspective native_file_string() is portable while string() isn't since it doesn't present the path in a way that the user recognize. Perhaps they need to be educated
I saw the smiley but don't understand if you agree or not.
Same thing with wide-character filenames. Why should boost::filesystem::path care if the path it carries is in a std::string or std::wstring? The wide- character filesystem operations can be difficult/impossible to implement on some systems but so are probably other operations. The alternative today is to not use boost::filesystem at all.
This is simply a question of timing. Beman had been working on a wide string extension for the library. I don't know where it stands, but clearly his intent is to add this capability. My understanding is he is recovering from an illness and is not following the list at the moment.
From the FAQ: "Wide-character names would provide an illusion of portability where portability does not in fact exist. Behavior would be completely different on operating systems (Windows, for example) that support wide-character names, than on systems which don't (POSIX). Providing functionality that appears to provide portability but in fact delivers only implementation-defined behavior is highly undesirable. Programs would not even be portable between library implementations on the same operating system, let alone portable to different operating systems."
From that I understood that wide-character support is against the portability philosphy and will not be implemented. Didn't know that someone is working on it.
Add to that the possibility to only iterate over specific files like "*.txt". Only the filsystem knows if "file.TXT" matches "*.txt" so the directory_iterator can't be used for this simple case
Search the developer mailing list for 'globbing iterator' and you should find links to a package that does this. It's not officially part of boost, but I think the author was planning on trying to include it.
As I said: 'Only the filsystem knows if "file.TXT" matches "*.txt"'. No external function can work it out by just looking at the filename. One example: Under Win32 you can have both case insensitive and case sensitive files even in the same directory (depending on a POSIX_somthing file attribute). AFAIK the only way to know which files matches "*.txt" is to pass "*.txt" to "FindFirstFile" but the directory_iterator always uses "*". I assume the situation is the same if you mount some case-insensitive filesystem under posix.
On Wed, 18 Aug 2004 14:41:19 +0000 (UTC), Martin wrote
Strangly enough boost::filesystem works activly against this by enforcing that you use "portable" filenames (unless you specificly turn it off).
Exactly. In many cases, making a completely portable application goes beyond compilation and includes the form of the data -- namely the file paths. There are many applications where the developer wants to ensure that the paths will work on all platforms without having to actually test on them.
Can you give an example of such an application because I have difficult to picture an application that will on purpose not accept all paths that are valid on the operating system where it runs.
All server/daemon type applications. 'Script-type applications' that use relative paths from the point of invocation and thus don't require user input. I've written gobs of these.
The only use I can see is that you at run-time can ensure that some application generated paths (e.g. path(root / "mysubdir")) are portable but why base an entire library on such a small thing.
It's a big thing to me.
Why would I want to force a windows user to only enter filenames that are portable?
That works for your application, but not for others. You are taking user input and want native paths. I think this option is clearly documented in the library.
as above. Why would an application work with paths that don't come from user input or a configuration file.
Sure, it might come from a config file, but that doesn't mean the path can't be relative and structured such that the config file is portable too. I don't want to maintain different config files for different platforms. There are all sorts of mistakes one might make with filenaming and it's nice to not have to test on all platforms to find that out.
From a user perspective native_file_string() is portable while string() isn't since it doesn't present the path in a way that the user recognize. Perhaps they need to be educated
I saw the smiley but don't understand if you agree or not.
I don't disagree that if you are taking user input, native paths might be the more 'portable approach'. I was lamely trying to make a joke...
Same thing with wide-character filenames. Why should boost::filesystem::path care if the path it carries is in a std::string or std::wstring? The wide- character filesystem operations can be difficult/impossible to implement on some systems but so are probably other operations. The alternative today is to not use boost::filesystem at all.
This is simply a question of timing. Beman had been working on a wide string extension for the library. I don't know where it stands, but clearly his intent is to add this capability. My understanding is he is recovering from an illness and is not following the list at the moment.
From the FAQ: "Wide-character names would provide an illusion of portability where portability does not in fact exist. Behavior would be completely different on operating systems (Windows, for example) that support wide-character names, than on systems which don't (POSIX). Providing functionality that appears to provide portability but in fact delivers only implementation-defined behavior is highly undesirable. Programs would not even be portable between library implementations on the same operating system, let alone portable to different operating systems."
From that I understood that wide-character support is against the portability philosphy and will not be implemented. Didn't know that someone is working on it.
Yep the docs give the wrong impression. But please read this: http://lists.boost.org/MailArchives/boost/msg60423.php
Add to that the possibility to only iterate over specific files like "*.txt". Only the filsystem knows if "file.TXT" matches "*.txt" so the directory_iterator can't be used for this simple case
Search the developer mailing list for 'globbing iterator' and you should find links to a package that does this. It's not officially part of boost, but I think the author was planning on trying to include it.
As I said: 'Only the filsystem knows if "file.TXT" matches "*.txt"'.
No external function can work it out by just looking at the filename. One example: Under Win32 you can have both case insensitive and case sensitive files even in the same directory (depending on a POSIX_somthing file attribute). AFAIK the only way to know which files matches "*.txt" is to pass "*.txt" to "FindFirstFile" but the directory_iterator always uses "*". I assume the situation is the same if you mount some case-insensitive filesystem under posix.
Ok, I misunderstood your first point. Anyway, it seems to me that the main 'problems' you are having are additional features that need to be contributed... Jeff
"Jeff Garland"
The only use I can see is that you at run-time can ensure that some application generated paths (e.g. path(root / "mysubdir")) are portable but why base an entire library on such a small thing.
It's a big thing to me.
It's clear there are two usage models, then, because I have the same experience as Martin does. It's unfortunate that the filesystem library is biased towards one model and makes the other one difficult to work with. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Fri, 20 Aug 2004 08:42:03 -0400, David Abrahams wrote
"Jeff Garland"
writes: The only use I can see is that you at run-time can ensure that some application generated paths (e.g. path(root / "mysubdir")) are portable but why base an entire library on such a small thing.
It's a big thing to me.
It's clear there are two usage models, then, because I have the same experience as Martin does. It's unfortunate that the filesystem library is biased towards one model and makes the other one difficult to work with.
I don't consider an extra constructor parameter 'difficult'. Sure, maybe the default should be flipped around -- I'd be fine with that. I give much credit to Beman for listening on this issue because personally I found a large lack of support for handling the portable path issue in languages 'perl' that supposedly provide good cross-platform libraries. Jeff
It's a big thing to me.
It's clear there are two usage models, then, because I have the same experience as Martin does. It's unfortunate that the filesystem library is biased towards one model and makes the other one difficult to work with.
I don't consider an extra constructor parameter 'difficult'. Sure, maybe the default should be flipped around -- I'd be fine with that. I give much credit to Beman for listening on this issue because personally I found a large lack of support for handling the portable path issue in languages 'perl' that supposedly provide good cross-platform libraries.
I agree, I would be very much against there being two (or more) path types, think of a path as a kind of handle to an object in the filesystem: the issue is what the constructor of path should take as an argument: * narrow or wide character string. * native or portable name. BTW, I've found the paths are usually constructed from a native path string in only one or two place in an application (for example when parsing the command line), all the rest is portable stuff. One thing I am tempted to complain about though: path's checking that a name is legal and portable maybe goes to far - if you are dealing with files that you know already exist, then manipulating that path shouldn't trigger the error checking. John.
John Maddock wrote:
BTW, I've found the paths are usually constructed from a native path string in only one or two place in an application (for example when parsing the command line), all the rest is portable stuff.
Not for me, we have quite a few places where the user has to save different files, and so we prompt with save file dialogs (windows) so paths for us nearly always come from native path strings. Cheers Russell
On Fri, 20 Aug 2004 08:42:03 -0400, David Abrahams wrote
"Jeff Garland"
writes: The only use I can see is that you at run-time can ensure that some application generated paths (e.g. path(root / "mysubdir")) are portable but why base an entire library on such a small thing.
It's a big thing to me.
It's clear there are two usage models, then, because I have the same experience as Martin does. It's unfortunate that the filesystem library is biased towards one model and makes the other one difficult to work with.
I don't consider an extra constructor parameter 'difficult'. Sure, maybe the default should be flipped around -- I'd be fine with that. I give much credit to Beman for listening on this issue because personally I found a large lack of support for handling the portable path issue in languages like 'perl' that supposedly provide good cross-platform libraries. Jeff
Jeff Garland wrote:
On Fri, 20 Aug 2004 08:42:03 -0400, David Abrahams wrote
"Jeff Garland"
writes: The only use I can see is that you at run-time can ensure that some application generated paths (e.g. path(root / "mysubdir")) are portable but why base an entire library on such a small thing.
It's a big thing to me.
It's clear there are two usage models, then, because I have the same experience as Martin does. It's unfortunate that the filesystem library is biased towards one model and makes the other one difficult to work with.
I don't consider an extra constructor parameter 'difficult'. Sure, maybe the default should be flipped around -- I'd be fine with that. I give much credit to Beman for listening on this issue because personally I found a large lack of support for handling the portable path issue in languages like 'perl' that supposedly provide good cross-platform libraries.
It is a question of ideology, not of difficulty. The current philosophy of the library tries to protect the user from himself, which is totally at odds with the spirit of C++. "Did you know that your path is valid on the current platform, and (usually) portable to all of the platforms you care about, but not portable according to our overly conservative rules? Here, take that exception and like it!" A "safety mechanism" that 98% of the people turn off as a matter of habit isn't something that increases safety.
participants (13)
-
Angus Leeming
-
Bronek Kozicki
-
Carlo Wood
-
David Abrahams
-
Delfin Rojas
-
Jeff Garland
-
John Maddock
-
Jonathan Turkanis
-
Martin
-
Peter Dimov
-
Russell Hind
-
Thomas Costa
-
Victor A. Wagner Jr.