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

From: Jason Stewart (res0054p_at_[hidden])
Date: 2002-01-29 11:58:08

>Using locales, you can lexicographically compare strings.  However, in this
>context, you need to compare strings while ignoring case, and I don't recall
>that being part of the locale framework.

OK, that means converting the strings. I think I read somewhere that 
lowercase is better for locales but I've already told you more than I know 
about locales.

> > Even without that need though, if I create a directory programmatically
>but
> > part of the name comes from the user then I could easily have mixed
> > separators. For instance, if the user entered "projects\myclass.cpp" and I
>
> > appended that to "/home/jason" then the result is
> > "/home/jason/projects\myclass.cpp". To convert this to backslashes, the
> > policy needs to recognize that both slash and backslash are valid
> > separators on Win32.
>
>My contention is that when you ask the object for the pathname, you get it
>in normalized form for the underlying filesystem.  IOW, all of the forward
>slashes would be changed to backslashes.

Exactly, that's why is_separator has to recognize both valid separators. 
The example I posted with the backward_separator always converts separators 
to backslashes. But if it doesn't recognize forward slash as a valid 
separator then it cannot do this properly. The example in the last post 
("/home/jason/projects\myclass.cpp") cannot be converted to canonical 
separators unless the Win32 version recognizes both forward and back slashes.

>You make a fine case for what you're after. However (you knew there'd be a
>"however," didn't you?), that usage only applies to Windows/DOS filesystems
>(and perhaps a few others).  Consider Unix: what do you get as the first and
>second values when doing a split()?  Does combining the first two elements
>make sense then?  What about with VAX or some other filesystem we try to
>support: does it make sense then?  The point is that what you're trying to
>do is rather specific to one (type of) filesystem and should not be part of
>the main class' interface.

Thank you, and yes, I had a feeling there would be a "however". But, (you 
probably knew that was coming as well), any system with volumes needs the 
same functionality (i.e. VAX). UNIX doesn't care. When you split 
"/home/jason" you get "/", "home/", "jason/" no matter what the flag is set 
to. If you split "c:/home/jason" on windows then you get "c:/", "home/", 
"jason/" if the flag says to include the volume. I could possible see doing 
away with the flag and always returning the root of the volume as the first 
item ("c:/" for Windows) but I don't like the idea of returning "c:", "/", 
"home/", "jason/". To me this means I have to do extra work most of the time.

Jason