|
Boost : |
Subject: Re: [boost] program_options: Support for open-end options
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-01-14 05:34:45
On Jan 13, 2013, at 10:39 AM, ST <smntov_at_[hidden]> wrote:
> On Sun, 2012-12-30 at 12:37 -0500, Rob Stewart wrote:
[Please don't overquote.]
>> However, another option in all of this is to just arrange for PO to collect all unrecognized options in a map keyed by command line position, leaving special case parsing to applications with unusual requirements. IOW, PO would be most extensible with such an ability, regardless of its ever gaining support for anything like you or I have mentioned herein.
> I thought about it, but the problem with this approach is, that you'll have to parse through the whole map for each group of open-ended options. Abilitiy to provide seperate map for each such group, is better IMHO.
Since command line parsing is done once, performance isn't critical, so your argument cannot be against the overhead of iterating the map. That leaves convenience, which can be addressed by a free function which provides the behavior you want built atop the unrecognized argument map I've suggested. The difference is that numerous schemes can be implemented similarly without further change to PO's implementation.
___
Rob
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk