|
Boost : |
From: Iain K. Hanson (iain.hanson_at_[hidden])
Date: 2003-08-20 08:14:48
On Tue, 2003-08-19 at 19:49, Brian Gray wrote:
> On Tuesday, August 19, 2003, at 12:35 AM, Yitzhak Sapir wrote:
> > My feeling from all these examples is that a path string is inherently
> > specific to the system for which it was specified, and can't really be
> > ported to anywhere else. Much like a string is usually inherently
> > specific in its encoding to the system-specified encoding. However,
> > the filesystem library can provide a portable way to manipulate this
> > system specific path, much like the string library provides a portable
> > way to manipulate the system-specific encoded string. In view of
> > this, why try for a "portable path" at all?
>
> This may have been covered already, but I would go further and assert
> that the very concept of a string path is non-portable.
It does not have to be. It is legal on both Windows and *nix'es to have
spaces in paths and filenames. This does not make it a good thing. I
like that when I create paths that they are portable and I can use this
to validate user input as well. When I have to traverse existing paths
then I expect to have to use native paths.
/ikh
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk