On Sep 13, 2013, at 7:09 AM, Tom Browder wrote: > You're welcome (after we see it really does the required job), but > where does the 700+ come from?
There are about 400 utilities and over 300 commands that parse options. There are already over 300 places getopt() is called where this interface would apply. >> 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.] What you describe is bu_arg_req_t; which I can see the self-documenting angle (I've just never been convinced of that for *booleans*, need at least three values). Here, the issue was making the *result* value a type, I'd argue that introduces an API consistency problem. If it's going to be more than a boolean, it might be warranted, but l think the interface needs to be as simple as it can be made. Consider also that every typedef, function, and #define in this new interface is going to (eventually) need to be fully documented with /** */ doxygen comments that explains what they are, what they work with, what the values mean. >> 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. The point wasn't to modify TCLAP. We should avoid doing that if we can, even. We're not required to expose every type they might define. As a template header, I'd see the need to define float and double functions so the appropriate instantiation type matches for the compiler. As C functions, however, that need isn't necessarily there. Certainly for parsing options, there only needs to be something flexible enough to capture the ascii form (which is probably a double). Until we encounter a need, we should probably be defining a limited a subset as possible to help keep the API simple. >> 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. Understood, the issue was more the discrepancy it introduces on the bu api as a whole. Do we want to turn all of our boolean arguments in other bu functions to enum typedefs? I'm not sure that self-documentation aspect pays for itself on that scale. If it's going to be more than a boolean, the concern is fully nullified and the typedef is warranted. > 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). I'm not sure I understand. TCLAP will expect what it's told to use, no? The point was to tell it to use long (instead of int) because int is problematic on Windows (it'll be a 32-bit type on a 64-bit compile, whereas long will be 64-bit). Cheers! Sea ------------------------------------------------------------------------------ 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 brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
