Boost logo

Boost :

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
> >the two strings first? (I think the best way to handle that is for both
> >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
> >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
> >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
> >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
> >signature; just its description. IOW, as with MakeAbsolute(), it should
> >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
> >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.

Susquehanna International Group, LLP

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