Re: [boost] Re: Design for a file system library

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-25 16:43:18

At 02:24 PM 2/25/2002, Jan Langer wrote:

 >i uploaded a new version of filesystem which meets bemans requirements.

Got it. Thanks. I'll wait to comment on it until I've looked it over in 
more detail.  I'm also hoping Jeremy Siek will comment on the attributes 
stuff since he is more of an expert on property map issues than I am.

 >several questions which came up during writing:
 >  - should a posix dir_it skip "." and ".."

I'd say the rule is do what the native platform API does.  It is hard for 
us to specify "always supply" as there may be no such animals on some 
platforms.  But to say "skip" makes it hard on those deliberately trying to 
exploit the platform.  But I could also live with "skip".  What do others 
think?

 >  - i currently implemented the classes with basic_ and typedef to avoid
 >the char template parameter. is this ok?

Sorry, I don't understand the question.  I used "CharT" for the name of the 
template parameter, because that is what it is called in the standard's 
description of basic_string.

 >  - what should the hierarchy iterator do in case of posix? just have
 >always only one element ("/")?

That was my thought too, although I'm not very knowledgeable about POSIX or 
Unix.

 >  - how can i get rid off the <char>'s behind the attributes? it does
 >not look well.

That's the sort of question I hope Jeremy can help with.  Quite a few of 
your attributes (is_directory, ...) should be required rather than 
optional. These "feel" to me as if they should be regular non-member 
functions. But I don't know if that makes sense in this context.

 >>How absolute() does its job internally is an implementation detail; that
 >>isn't a good argument for exposing getcwd/chdir.
 >
 >what should absolute() do? it isn't mentioned in the requirements as a
 >function.

Because I'm not sure if it is in fact a requirement.  It would take a path 
and return an absolute path (which might in fact be the same string).

 >
 >> >I guess if the only access to the current working dir is by calling
 >> >absolute(".") I'd live with it but I wouldn't be happy.
 >> >chdir is useful for a few limited purposes, as long as you ensure all
 >> >relative paths are kept to one thread.  It's also useful when forking
 >> >child processes, but in that case you need a specialised interface,
 >> >because under NT you have to do it quite differently. I already
 >> >started work on a class for forking subprocesses, not sure if I
 >> >posted anything here.
 >>
 >>Everything you at talking about is non-portable.  "." for example. Fine 
if
 >>you want to do that in your own program, but I'd like that sort of
 >>non-portable thinking not to seep into the interface.
 >
 >i would like to see chdir-functions since its not even possible to write
 >a ls-like-program without it. it is not absolutely necessary but it
 >would make many things easier (eg. ls).

Why wouldn't it be possible?  The first line of your example above would 
change from:

   directory_iterator i (current_directory <char> ()),  end;

to:

   directory_iterator i (""),  end;

In other words, relative paths can be relative to the current directory 
internally even if it isn't explicitly exposed.

--Beman