[program_options] implicit value and non-adjacent tokens
Hi, some time ago, program_options was modified so that options with implicit value would only take value from the same token. Previously, one could have: ./program -a foo -b # uses 'foo' as value for 'a' ./program -a -b # uses some default value for 'a' ./program -b # has no value for 'a' Now, the first syntax interprets 'foo' as positional option, and one has two write ./program -a=foo Ever since, I hear concerns from users about this behavior. Maybe not very loud, but quite consistent. Maybe, the new behavior is not very good, indeed, because it now mixes syntax matter (whether value is in the same token) with semantic matter (whether an option has implied value). I am considering reverting this change for next version of Boost. Does anybody have opinions either way? Thanks, Volodya
Hi,
It is definitely how I see it.
Right after this change, which broke the tests of my program, I implemented
a value wrapper which mimics the original behavior.
I don't think there's is a single right way to do it, but consistency
matters.
Thanks,
Benedek
On Dec 21, 2016 08:37, "Vladimir Prus"
Hi,
some time ago, program_options was modified so that options with implicit value would only take value from the same token.
Previously, one could have:
./program -a foo -b # uses 'foo' as value for 'a' ./program -a -b # uses some default value for 'a' ./program -b # has no value for 'a'
Now, the first syntax interprets 'foo' as positional option, and one has two write
./program -a=foo
Ever since, I hear concerns from users about this behavior. Maybe not very loud, but quite consistent. Maybe, the new behavior is not very good, indeed, because it now mixes syntax matter (whether value is in the same token) with semantic matter (whether an option has implied value).
I am considering reverting this change for next version of Boost. Does anybody have opinions either way?
Thanks, Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost
I believe this broke for my command lines. http://lists.boost.org/Archives/boost/2016/10/231134.php Never understood what happened till now and know that I can't get users to change so went back to 1.57
Hi, As of 1.63.0 this new behavior still breaks my command line and I have to revert back to using boost 1.57.0. Is there a work around to revert this behavior in the 1.63.0 release? Any hope for those of us who use positional for file paths? On 12/21/2016 02:36 AM, Vladimir Prus wrote:
Hi,
some time ago, program_options was modified so that options with implicit value would only take value from the same token.
Previously, one could have:
./program -a foo -b # uses 'foo' as value for 'a' ./program -a -b # uses some default value for 'a' ./program -b # has no value for 'a'
Now, the first syntax interprets 'foo' as positional option, and one has two write
./program -a=foo
Ever since, I hear concerns from users about this behavior. Maybe not very loud, but quite consistent. Maybe, the new behavior is not very good, indeed, because it now mixes syntax matter (whether value is in the same token) with semantic matter (whether an option has implied value).
I am considering reverting this change for next version of Boost. Does anybody have opinions either way?
Thanks, Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
This is a possible fix (subject to typos) : template <typename T> struct greedy_implicit_value : public po::typed_value<T> { using base = po::typed_value<T>; greedy_implicit_value(const T& value) : base(nullptr) { base::implicit_value(value); } bool adjacent_tokens_only() const override { return false; } unsigned max_tokens() const override { return 1; } }; template <typename T> po::typed_value* implicit_value(const T& value) { return new greedy_implicit_value<T>(value); } Benedek
Will something be done for up coming 1.64 release? Was this replacing code in boost program options to make it work or override in an application? On 01/05/2017 03:20 AM, Benedek Thaler wrote:
This is a possible fix (subject to typos) :
template <typename T> struct greedy_implicit_value : public po::typed_value<T> { using base = po::typed_value<T>;
greedy_implicit_value(const T& value) : base(nullptr) { base::implicit_value(value); }
bool adjacent_tokens_only() const override { return false; } unsigned max_tokens() const override { return 1; } };
template <typename T> po::typed_value* implicit_value(const T& value) { return new greedy_implicit_value<T>(value); }
Benedek
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (3)
-
Benedek Thaler -
Roger Martin -
Vladimir Prus