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

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-29 11:43:58

From:	Jason Stewart [SMTP:res0054p_at_[hidden]]
> 
> Yes, I meant locales. Would you actually convert the strings or can
locales 
> compare without regards to case?

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.

> > > >ForwardSeparator::isSeparator()'s (is_separator()'s) implementation
> >should
> > > >just be...
> > >
> > > Possibly, in my software, I tend to convert all separators to forward
> > > slashes since it works on all platforms that I deal with. However,
users
> > > still tend to enter backslashes on windows. Since I want to convert
them I
> > > like isSeparator to return true for both.
> >
> >If you're trying to create a pathname programmatically, and then you need
to
> >display it to the user, you'll want it to appear in the "correct" format.
> >For Windows, that means using backslashes, even if the APIs will accept
> >forward slashes.
> 
> It depends. Many times yes. Much of the software I have worked on recently

> needed to create and store paths that worked on UNIX and Windows. Since 
> Windows handles forward slashes but UNIX doesn't handle backslashes we 
> converted everything to forward slashes.

That's fine.  You need a mechanism for doing that conversion.  Nevertheless,
the native format for Windows is with backslashes, so that's what one should
get normally.  I'd even venture to say that your version can be a special
policy class that forces everything to forward slashes, even though its
working on a Windows filesystem.

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

> > > >Pathname::Split() should not return a vector.  Instead, make it a
member
> > > >template that takes an output iterator.  I don't think the parameter
is
> > > >necessary.  The caller can skip the first string if they don't want
the
> > > >volume.  If you opt to keep that parameter, then create an enumerated
> >type
> > > >to control the behavior.
> > >
> > > The parameter decides whether the volume should be included in the
first
> > > parameter or not. Sometimes it is helpful to get the first part as
> > > "c:/data" instead of "c:" and "/data". I agree with the iterator
though.
> > > I'll look into it.
> >
> >I understand the reason you included it.  I was just pointing out that
the
> >caller can assemble the pieces as they see fit, or can ignore the first
> >value altogether, if appropriate.  What if the caller doesn't want the
> >extension or the filename?  You haven't provided options for those.  If
you
> >want to offer this kind of flexibility, then I suggest taking pointers to
> >strings for each possible component.  If a pointer is non-null, write the
> >corresponding component through the pointer.
> 
> I am open to your point of view, I just think that much code is easier to 
> write if you can know that the first piece you get back is the root of a 
> volume, not just the volume name itself. For instance:

[snipped code illustrating use of root versus volume name]

> In the second case you have to get the volume and add it to your temporary

> path, increment your iterator, then go into your loop. In the first case 
> you don't have to handle the volume as a special case.

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.

(Like the UNC handling I mentioned before, perhaps this is best suited to an
extra function in the policy class.)

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