On Thu, Sep 12, 2013 at 12:01 PM, Christopher Sean Morrison
<[email protected]> wrote:
> On Sep 12, 2013, at 7:50 AM, Tom Browder wrote:
>> I think I have it in shape enough for criticism, but I'm still working on it.
Duh, so far there's no way to get the successfully parsed values back
to the caller--but I have a plan!
> Seriously big thank you for working on this... we'll only need to
> use this interface in about 700+ places, probably more.
You're welcome (after we see it really does the required job), but
where does the 700+ come from?
> Looking at the bu_opt_parse.h, a few questions and comments come to mind:
...
> 1) bu_arg_parse_result_t seems unnecessary and redundant with BRLCAD_OK /
> BRLCAD_ERROR
My goal was to have a struct that has a place for all the possible
TCLAP inputs. I also tried to make it as self-documenting as
possible. The TCLAP docs are a little confusing but the two boolean
values are to determine (1) is the arg required and (2) does it need
an explicit value besides the default (e.g., -j=<some integer>). [I
will look again to see if I'm interpreting that correctly.]
> 2) bu_arg_value_t has different float types but not different int types?
I just blindly used the same types as TCLAP. Your idea is fine and we
can mod TCLAP if we need to handle wider types.
> 3) bu_arg_req_t seems unnecessary? we use int for booleans elsewhere.
> perhaps a uint8_t
That was intended to help the self-documenting.
> 4) is there any value in making the sizes explicit in bu_arg_value or is the
> variable size important?
If you mean like int vs. long, I think I will avoid trouble at first
by giving and receiving what TCLAP expects. After the harness works,
then try fiddling with it (it may make handling a little more complex
behind the scenes).
> 5) suggest including the bu_arg_value type with the value, not in bu_arg_vars
> separately. something like typdef struct {int type; union {char c; long i;
> double d; char *s;}} bu_arg_value_t;
I'll try that.
> 6) all typedefs should be bu_arg_something_t for bu API consistency, or we
> can just be explicit with "struct bu_arg_value *" for example. the
> indirection doesn't buy much in this context, saves few keystrokes.
Roger.
> 7) bu_opt_parse() looks pretty cool. shouldn't argv be const? (i.e., char *
> const argv[]). matches getopt signature.
Yes, thanks.
Best regards,
-Tom
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
