RE: [boost] Re: the first version of abstract path manipulation c lass (interface)

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-25 09:56:10

From:	Jason Stewart [SMTP:res0054p_at_[hidden]]
> 
> Windows will preserve case. Yes, there is a shortname but it is for 
> compatibility, not the primary way of storing it. To force all filenames
on 
> Windows to be either upper or lowercase would be distasteful.

I'm pretty sure that in Windows 95, if not in any later versions, the long
filename was stored in multiple directory entries following the 8.3 entry.
Those extra entries contained a flag that indicated they were part of a long
filename.  The point is that 8.3 was the primary name, and the long filename
was hacked in and could get disconnected.  Perhaps that's not the case with
newer DOS-based versions of Windows.  I know it is not the case with NTFS
filesystems.

My point was that an application trafficking only in 8.3 names -- could
there still be any? -- would expect to work with upper case pathnames.  If
there's some other OS with some other naming convention, then it would be
ideal to support that convention, and less the exact conventions of various
versions of Windows.

> I have reworked the class that I submitted earlier (its not complete yet,
I 
> just wanted to see what people thought about the interface). 
> http://stewart.simwright.net/samples/Pathname.h

I don't know.  I get a 404: Not Found on that URL.

> I added two template parameters, the first one is basically a traits class

> to tell it how to handle case. It has two comparison functions, equals and

> less, and a transform function that can change the case. I provided 4 
> sample implementations, CaseSensitive, CaseInsensitive, Lowercase, and 
> Uppercase.

I like that you use a function to transform the case.  That leaves the logic
totally in the hands of the class user.  That means that some OS that always
uses title case, or something silly like that, could fit fine.

> The second template parameter tells it how to handle the separator. It has

> functions to compare a character to see if it is a valid separator, to 
> return the separator, to transform (i.e. force all forward slashes to 
> backslashes), and to check for duplicate separators (some platforms ignore

> multiple separators, others don't).

I don't want to further complicate matters, but I have to ask:  Are there
any platforms that use more than a single character as the separator?

"transform" doesn't evoke the purpose of the function fully to me.  How
about "to_native" or something like that?  Yes, it potentially transforms
one representation to another, but the point is to turn some common
representation or variant into the standard, native representation.

Does the "transform" logic take a string and return another?  If so, would
it be better to have a function that takes a character and returns the
transformed character?  Then, the pathname class can walk the string and do
an in-place update of the string, avoiding a copy.  That also makes the
policy class simpler.

When checking for duplicate separators, does the policy class' function do
the work or does it simply indicate whether duplicates are permissible?  The
latter would leave the string manipulation work in the pathname class,
making the policy class simpler.

> Also, this class doesn't do much file I/O, it is solely for pathname 
> processing., not directory processing. From some of the other messages
I've 
> read, people seem to feel this is the way to go.

What file I/O is needed for pathname processing?  What aspect of pathname
processing am I missing that you feel is needed in this class and requires
filesystem access?

Rob
Susquehanna International Group, LLP
http://www.sig.com