Re: [Boost-users] Boost Program Options: Any way to have variable number of "objects" each with parameters?
Here is what I have come up with. Any feedback? I first thought of something like this: CircleRadiuses= 4 7 3 . It's okay for objects with only one value (like Circles) but clumsy and unintuitive for objects with more than one parameter like RectangleHeights= 5 3 7 . RectangleWidths= 10 4 16 . Although I would like to support "any number" of objects, the reality is that a likely number is three or four, so restricting it to a maximum of nine should not be a problem. So here is my plan. Something like [Rectangle1] Height=5 Width=10 [Rectangle2] Height=3 Width=4 and so forth through Rectangle9. Same sort of deal for Circle1 through 9. (I think counting from 1 is more user-friendly for people who are not C programmers.) So, any feedback? Any better way to solve this problem? Charles From: Charles Mills [mailto:charlesm@mcn.org] Sent: Wednesday, June 20, 2012 6:20 PM To: 'boost-users@lists.boost.org' Subject: Boost Program Options: Any way to have variable number of "objects" each with parameters? I really like the Boost Program Options library. I've used it for one program now with great effect and I'd like to use it for another, but can't figure out how to structure what I need to do so that Boost PO could handle it. I am solely interested in the ".ini file" for this - command line is irrelevant. The problem is "how does a program allow the specification of a variable number of 'objects' each of which has parameters of its own?" Here is a hypothetical program that exemplifies the problem. Suppose a program were going to create multiple geometric shapes of some sort. An ideal (unsupported by PO) .ini file might look like rectangles=3 rectangle[0].width=5 rectangle[0].height=10 rectangle[1].width=3 etc. circles=2 circle[0].diameter=4 etc. Can anyone suggest a way to accomplish this with Boost PO? I'm real flexible on what the .ini file might look like so long as it solves the problem and is reasonably explicable to a user. (No need for it to look almost like the above.) Thanks, Charles
participants (1)
-
Charles Mills