Boost logo

Boost :

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
> > 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at