Re: [boost] Filesystem Review

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-09-23 14:56:33

At 07:27 AM 9/23/2002, Thomas Witt wrote:

 >Here is my review of the filesystem library.
 >
 >Vote
 >- ------
 >
 >I vote for acceptance of the library into boost.

Thanks!

 >Details:
 >- ---------
 >
 >- - Design
 >
 >I am very sceptic with regard to the implicit conversion string <-> path. 
I
 >did not have the time to evaluate it in detail but if I had to vote now I 

 >would disallow it.

To be specific, there isn't any implicit conversion from path to string. 
That would have been seriously problematic.

There are conversion constructors for path from std::string and const char 
*.

Without them, you would have to write:

      if ( exists( path( "foo" ) ) ) ...

With them, you can write:

      if ( exists( "foo" ) ) ...

The improved ease-of-use seems quite important to me.  Some early versions 
of the library didn't have the conversions, and it was painful to use them.

Because path is only present in contexts where conversion from strings is 
normal practice, the conversion seems benign to me.  Am I missing 
something?

 >I still like my ideas about root :-).

It may be awhile before those issues get resolve; I'm about to leave on a 
ten day trip, and don't want to resolve them when under time 
pressure.  I'll go over any resolution with you before it is finalized.

(If all goes as planned, Thomas and I will see each other at the upcoming 
C++ committee meeting in four weeks.)

 >I think Vladimir Prus has a point with his comments regarding exceptions. 
I
 >do not think that the filesystem library should hide filesystem 
limitations
 >with respect to rename, but the user should be able to act accordingly.

Understood.  See my comments on his posting.

 >- -Implementation
 >
 >As stated earlier the iterator implementation needs to be fixed.

Yes, for sure.

 >I am not an expert in WIN32/POSIX API programming so I will not comment 
on
 >the use of the API.

We do need experts to look at the implementations.

I'm hoping we will get Mac OS volunteers to do an implementation, too.

 >- - Documentation
 >
 >remove_all should be documented.

Its a bit terse, that's for sure:-)  Will do.

 >Further development:
 >- ---------------------------
 >
 >I do believe the scope of the library should be broadened (does this make 

 >sense?). Limiting the scope to script like operations has the danger of
 >being almost usable in the majority of applications.

I hope use won't be limited to script-like apps, but we had to start 
somewhere. That starting point focused a lot of discussion, and led to the 
path class, which solved a portability problem that was a major stumbling 
block to prior efforts.

Once we get the current library into Boost (assuming it is accepted, but no 
one has any killer arguments against so far), and get a bit more experience 
with it, then let's talk about how to broaden it.

 >As mentioned by others before file/directory property support would be a
 >worthwile extension.

Yes.  I hope Jan Langer will propose that.

 >I strongly believe that C++ has to provide better i18n support.
 >With respect to this I do not buy the arguments regarding wchar_t 
support.
 >There are quite a few non latin languages in the world and the need to
 >support them is ever increasing. Either C++ does something about this
 >problem or application programming will not be done using stdc++.

I certain agree with the generalities of that, but it is hard to move 
forward with concrete proposals with agreed upon semantics.

Also keep in mind that in the case of paths, multi-byte character strings 
should work OK with boost::filesystem, and that helps some folks a great 
deal.

 >Last but not least, thanks Beman for all the work.

Lots of people have contributed, and are still contributing.

--Beman