Subject: Re: [boost] [filesystem] basic_path::operator>> issue for paths with spaces
From: Andrew James (aj_at_[hidden])
Date: 2008-09-22 15:13:56
In the past, due to the standard's approach to treating all string extraction as ending upon encountering a space, I have tended to insert the length of the string a space and then characters.
"My Name" serialized becomes "7 My Name"
in >> w; // read 7
in.ignore(); // ignore space
in.width( w ) // minimum extraction for string
in >> s; // extract string
I like this approach better than using some "sentinel" character as there's no need to perform character by character extraction one the length is known. Not to mention a path can now have a ' ', a '"', etc....
Any way you slice it, there's a problem as the serialization protocol may need to change. How will previous serialized paths be extracted?
On 9/22/08 11:48 AM, "Johan Råde" <rade_at_[hidden]> wrote:
Scott McMurray wrote:
> On Mon, Sep 22, 2008 at 14:14, Johan Råde <rade_at_[hidden]> wrote:
> That sounds good, but how would it handle paths with "s in them?
> $ touch '"'
> $ rm '"'
> rm: remove regular empty file `"'? y
> $ touch '\'
> $ rm '\'
> rm: remove regular empty file `\\'? y
> ~ Scott
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I don't know. I only have experience with Windows,
where spaces are common and "s are not allowed in path names.
It is a common convention on Windows
to surround paths, that contain spaces, by quotes.
How is this problem handled on Unix?
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk