From: Jan Langer (jan_at_[hidden])
Date: 2002-03-05 15:42:28
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.
i think initial_directory is a nice solution to the problem, although
its not far from current_directory.
>template< typename CharT >
why do we need this function. i think something like a
hierarchy_iterator would solve this far better. 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.
>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)?
>TODO: We need an overall review of what "" means as a path arg in all file
>system functions (not just the ones in this header.)
>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?
it would be sufficent if we overload compose for a reasonable number of
-- jan langer ... jan_at_[hidden] "pi ist genau drei"
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk