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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-05 20:40:18

At 03:42 PM 3/5/2002, Jan Langer wrote:

 >On Mon, 4 Mar 2002, Beman Dawes wrote:
 >>The upshot of all this is that the answer to Jan's question about the
 >>meaning of "" as a path is either:
 >>
 >>   (1) An error.
 >>   (2) initial_directory().
 >>   (3) root_directory().
 >
 >i'd take (1). its the simplest approach.

Yes, the more I think about it, the better (1) looks.

 >i think initial_directory is a nice solution to the problem, although
 >its not far from current_directory.

Not far in usage, but hugely safer because it has a constant value, rather 
than a value which may be changed unexpectedly by a library function, 
another thread, or even the system.

 >
 >>template< typename CharT >
 >>std::basic_string<CharT> root_directory();
 >
 >why do we need this function. i think something like a
 >hierarchy_iterator would solve this far better.

I was trying to avoid a specific hierarchy_iterator by saying that a 
regular directory_iterator acted like a hierarchy_iterator if given a 
special argument.  I guess the name root_directory() is confusing.

 > eg. if i want to write
 >something to the root directory. it would not be allowed on win32. but
 >if i call directory_iterator (root_directory ()) it fits for win32
 >("c:") but not for posix ("/bin").
 >a hierarchy_iterator however returns "/" on posix and "c:" on win32.

I was assuming directory_iterator( root_directory() ) would return all the 
directory_entry's in "/" for POSIX, and a:,b:,c:, etc for win32.

 >>TODO:  We need a safe way to turn a relative path into an absolute path.
 >>Perhaps absolute( relative-to, path ) which returns path if it is 
already
 >>absolute, or path( relative-to, path ) if path is relative.
 >
 >i'd like to see an overloaed function with just one argument path
 >returning absolute (initial_directory (), path)?

Yes, that might be useful.

 >>TODO:  Two argument path composition is hopeless in trying to write real
 >>code. Need n-argument.  (I realize that argues for a path composition 
type
 >>which could overload operator+ appropriately. I'm not thinking of
 >replacing
 >>the string type in all path args, just the possibility of a path
 >>composition type used only when composition is needed, with an automatic
 >>conversion to string.
 >
 >i think we should have either a functional solution to path manip.
 >questions or a class for it, but not a mixture of both. what will you
 >say if someone asks why the other functions (absolute, branch, leaf,
 >...) are not members?

I can make a good argument, but not tonight:-)

 >it would be sufficent if we overload compose for a reasonable number of
 >arguments (5?).

I'm not sure. That might be OK. It really gets hairy to do it 
portably.  What POSIX and Windows do with "/" can take four or more 
separate delimiters on systems.  What you are composing impacts the choice 
of delimiter.  So composing a directory path is different from composing a 
file path. Bah!

But whatever the choice is, it won't impact the rest of the design the way 
we have it now, since it all turns into a string sooner or later.  So 
compose issues can safely be left until later.

--Beman