Re: directory iteration / path manipulation

From: mfdylan (dylan_at_[hidden])
Date: 2002-01-24 01:09:45

--- In boost_at_y..., Jason Stewart <res0054p_at_g...> wrote:
> On unix systems the Drive functions don't do anything. There 
> is a compile time constant that defines whether comparisons are 
> case-sensitive or not.
> 
I think on unix drive() can sensibly return '/' (I found that useful 
in some cases).  Case-sensitivity needs to be a runtime flag though, 
on my PC I use a mixture of file systems that are both case sensitive 
and insensitive, and even needs to manipulate pathnames that are 
intended for other systems.

Probably every man, woman and their pet yak have written both 
pathname parsing and directory manipulation 
(creation/iterating/removal) classes, and probably most people (me 
including) combined the two.

In a purest sense the concept of a pathname (that can be broken up 
into components and have those components easily modified) should be 
separate from the file-system object the pathname refers to.
Something like:

pathname name("./options.dat")
file f(name);
if (f.exists())
{
    f.copy_to(name.set_extension("bak"));
    f.delete();
}
file_processor proc; // some sort of visitor
directory d(name.directory());
for (directory::iterator i = d.begin(); i != d.end(); ++i)
{
   filebase& f = *i;
   f.accept(proc);
   f.move_to("/tmp");
}

where file and directory could derive from the abstract class 
filebase.  An attempt to create a directory from a filename or a file 
from a directory name would simply throw an exception.
Implementing the directory iteration would presumably involve 
dynamically allocating objects for each directory entry, which may 
not be super efficient but compared to the actual OS work of reading 
the directory would be trivial.
I also think 'pathname' should come in char and wchar_t flavours, 
with both versions supporting conversion to const char* so it can be 
used with fstream/filebuf.

Dylan