Program Options of Filesystem Path's - confused!
OK, If I take a po:wvaluestd::wstring()->notifier(&datadir_set) the string gets passed to datadir_set, and within that function it implicitly converts the string to a fs::wpath instance to call set_me. It works as expected. void set_me (const fs::wpath& p); void datadir_set (const std::wstring& s) { wcout << L"** set data dir to " << s << L".\n"; set_me (s); } However, if I declare the program option as po::wvaluefs::wpath()->notifier(&set_me) then when it runs I get "invalid option value". It apparently can't convert the argv token into a wpath? But it's not a compile-time error so it thinks it knows how to, but gets an error actually doing it? I have no trouble passing long string literals to the constructor, e.g. fs::wpath f1 (L"C:\\here\\there.txt"); The program option takes "." on the command line just fine, so it's the specific value of the string it doesn't like! I tried with Unix-style slashes, with no difference. A little experimenting tells me that it doesn't like having spaces in the string! Note that the quotes are understood by the run-time library that calls main, so the whole string (without surrounding quotes) is present in one element of argv. It works just fine when taking the argument as a string. This seems like a bug, somewhere. --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
John Dlugosz wrote:
OK, If I take a po:wvaluestd::wstring()->notifier(&datadir_set) the string gets passed to datadir_set, and within that function it implicitly converts the string to a fs::wpath instance to call set_me. It works as expected.
void set_me (const fs::wpath& p);
void datadir_set (const std::wstring& s) { wcout << L"** set data dir to " << s << L".\n"; set_me (s); }
However, if I declare the program option as po::wvaluefs::wpath()->notifier(&set_me)
then when it runs I get "invalid option value". It apparently can't convert the argv token into a wpath? But it's not a compile-time error so it thinks it knows how to, but gets an error actually doing it?
I have no trouble passing long string literals to the constructor, e.g. fs::wpath f1 (L"C:\\here\\there.txt");
The program option takes "." on the command line just fine, so it's the specific value of the string it doesn't like! I tried with Unix-style slashes, with no difference.
A little experimenting tells me that it doesn't like having spaces in the string! Note that the quotes are understood by the run-time library that calls main, so the whole string (without surrounding quotes) is present in one element of argv. It works just fine when taking the argument as a string.
This seems like a bug, somewhere.
Try: lexical_castfs::wpath(fs::wpath("the path that fails")) If that fails, it means operator>> is mishandling spaces in paths. - Volodya
On 14 August 2010 06:35, Vladimir Prus
John Dlugosz wrote:
A little experimenting tells me that it doesn't like having spaces in the string! Note that the quotes are understood by the run-time library that calls main, so the whole string (without surrounding quotes) is present in one element of argv. It works just fine when taking the argument as a string.
This seems like a bug, somewhere.
Try:
lexical_castfs::wpath(fs::wpath("the path that fails"))
If that fails, it means operator>> is mishandling spaces in paths.
If this filesystem v2 or v3? In filesystem v3, the stream extractor uses whitespace as a separator (correctly IMO), so filenames with spaces have to be quoted. I suspect the issue is that the filename has already have been unquoted by the shell. Your test will work, since the filename is quoted as it's written to the stream, and then unquoted as it's extracted. But you'll see the error with: lexical_castfs::wpath("the path that fails") Does program options ever do that? Btw. in filesystem v3, 'wpath' is just a typedef for 'path'. Daniel
Daniel James wrote:
On 14 August 2010 06:35, Vladimir Prus
wrote: John Dlugosz wrote:
A little experimenting tells me that it doesn't like having spaces in the string! Note that the quotes are understood by the run-time library that calls main, so the whole string (without surrounding quotes) is present in one element of argv. It works just fine when taking the argument as a string.
This seems like a bug, somewhere.
Try:
lexical_castfs::wpath(fs::wpath("the path that fails"))
If that fails, it means operator>> is mishandling spaces in paths.
If this filesystem v2 or v3? In filesystem v3, the stream extractor uses whitespace as a separator (correctly IMO), so filenames with spaces have to be quoted. I suspect the issue is that the filename has already have been unquoted by the shell.
Your test will work, since the filename is quoted as it's written to the stream, and then unquoted as it's extracted. But you'll see the error with:
lexical_castfs::wpath("the path that fails")
Does program options ever do that?
Yes, of course. It takes string from command line, and does lexical_cast on it. So, it seems like the only approach is to specialize lexical_cast for wpath/path? - Volodya
On 14 August 2010 11:08, Vladimir Prus
Daniel James wrote:
Your test will work, since the filename is quoted as it's written to the stream, and then unquoted as it's extracted. But you'll see the error with:
lexical_castfs::wpath("the path that fails")
Does program options ever do that?
Yes, of course. It takes string from command line, and does lexical_cast on it. So, it seems like the only approach is to specialize lexical_cast for wpath/path?
I don't know. I'll take this up in a new thread on the development list. Daniel
lexical_castfs::wpath(fs::wpath("the path that fails"))
Making the string literal a L-string (L"the path that fails"), it won't compile. The spiel is attached at the end of this message.
If that fails, it means operator>> is mishandling spaces in paths.
lexical_castfs::wpath("the path that fails")
Correcting to make the string L, it throws an exception "bad lexical cast: source type value could not be interpreted as target"
You ask if it's version 2 or version 3 of the fs library:
It doesn't say! However, the href for the docs says "this is version 2", which was "default for Boost 1.44 only". But I have Boost 1.43. The headers don't show version numbers, but do show a date of 2005. Should I move to version 3? I guess Boost 1.44 is hot off the press so it's normal enough that I don't have it?
===
Compiler output for line 13 which is
fs::wpath p1= lexical_castfs::wpath(fs::wpath(L"the first path that fails"));
Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
fs_test.cpp
D:\boost_1_43_0\boost\lexical_cast.hpp(595) : error C2679: binary '<<' : no operator found which takes a right-hand operand of type 'const src' (or there is no acceptable conversion)
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE\ostream(653): could be 'std::basic_ostream<_Elem,_Traits> &std::operator <<
On 16 August 2010 22:58, John Dlugosz
lexical_castfs::wpath(fs::wpath("the path that fails"))
Making the string literal a L-string (L"the path that fails"), it won't compile. The spiel is attached at the end of this message.
If that fails, it means operator>> is mishandling spaces in paths.
lexical_castfs::wpath("the path that fails")
Correcting to make the string L, it throws an exception "bad lexical cast: source type value could not be interpreted as target"
You ask if it's version 2 or version 3 of the fs library: It doesn't say!
Sorry, that was my mistake. Version 2 has the space problem in 1.43, but not in 1.44. Version 3 is introduced in 1.44 but works in a different way and has the space problem. I don't know how well it (or lexical cast) handles L-strings. I've brought up the space issue on the development list, but I'm having a bit of trouble explaining it. Until a conclusion is reached, I'd suggest using strings in program options, and then constructing the filesystem path yourself. Daniel
Sorry, that was my mistake. Version 2 has the space problem in 1.43, but not in 1.44. Version 3 is introduced in 1.44 but works in a different way and has the space problem. I don't know how well it (or lexical cast) handles L-strings. I've brought up the space issue on the development list, but I'm having a bit of trouble explaining it. Until a conclusion is reached, I'd suggest using strings in program options, and then constructing the filesystem path yourself.
Daniel
Food for the thought for the developers: In general, it would be confusing for lexical cast to do something different than a static cast, i.e. the constructor that takes a string as an argument. (In those cases where the ctor is indeed "converting" the string. When such a ctor form does something different, it makes sense that the lexical cast would be totally different.) Thanks, --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
participants (3)
-
Daniel James
-
John Dlugosz
-
Vladimir Prus