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

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-29 09:21:02

From:	Jason Stewart [SMTP:res0054p_at_[hidden]]
> 
> >Shouldn't equal() and less() in Lowercase and Uppercase coerce the case
of
> >the two strings first?  (I think the best way to handle that is for both
to
> >force the strings to lower case for comparison, as there are non-English
> >language problems going from lower to upper case.)
> 
> I don't know, maybe they should, I guess for broad acceptance it might 
> should use locals (I've never used locals).

I presume you meant "locales."  That's how you would do the case
conversions, but the issue of which case remains.

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

> >Pathname::MakeAbsolute() should take the "current directory" as a
parameter.
> >Not only does that do what your version does, if the caller supplies the
> >real current directory, but it also allows the caller to convert a
relative
> >path into an absolute path based upon any path of their choice.  This is
> >applicable for situations in which the program is given a relative path
> >based upon the user's home directory or some data repository.
> >
> >Pathname::MakeRelative() says that the parameter defaults to the cwd, and
> >yet the parameter has no default value.  Nevertheless, I wouldn't change
the
> >signature; just its description.  IOW, as with MakeAbsolute(), it should
be
> >up to the caller to provide the cwd, if that's what they want.
> 
> In retrospect, are MakeAbsolute or MakeRelative similar to Exists in that 
> they should be handled outside the class?

No.  There is no filesystem interaction necessary.  They are just
manipulating the head of the pathname.  Exists() has to interact with the
filesystem to determine whether the file exists.

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

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