Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk