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

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-30 08:06:48

From:	John Maddock [SMTP:John_Maddock_at_[hidden]]
> 
> >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 in the hard-coded path strings, but that doesn't mean the class
should maintain those slashes.

> >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.
> 
> Surely the whole point is that we would use the pathname class to handle
> programmatic creation of pathnames:
> 
> pathname path; // current directory
> path.join(foo).join(bar);
> std::cout << path;

Jason's example was more like this:

    pathname path(filesystem::cwd()); // "pathname" shouldn't access the
filesystem
    path += "foo/bar";
    std::cout << path;

IOW, the program knows some portion of the path, perhaps from a
configuration file, and appends that in one operation, rather than breaking
it into pieces and append each piece individually.  Thus, the supplied path
might contain forward slashes, whereas the output looks like this:

> prints ./foo/bar on unix but .\foo\bar on win32 and :foo:bar on the mac.

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