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