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
> - 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
> - 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
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
>>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
directory_iterator i (current_directory <char> ()), end;
directory_iterator i (""), end;
In other words, relative paths can be relative to the current directory
internally even if it isn't explicitly exposed.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk