On Sep 18, 2013, at 5:30 PM, Tom Browder wrote: > So it's okay for main functions? If so, that at least takes care of > 400+ progs, right?
Heh, but we don't really want to end up with two interfaces when they are all argc/argv processing and need option parsing. Right? If someone ever did use it inappropriately, I'd be surprised, and that'd be a crazy-difficult bug to identify due to the time-dependent random bad behavior. Looking over where things are at, it's looking pretty good to me. I like how the two primary structs are laid out. I'd still be inclined to drop the two enum that are just boolean flags, just for API simplicity, but not an issue to have them either (just more work to document them). I realize that you're matching tclap, but mixing camelcase with underscores goes against HACKING .. and those tclap arg type names don't seem obvious to me without an explanation. Question, though, why is it important that the bu_arg_value_t first enum be an integral type? Also, is it possible to have an optional arg value? It's clear that BU_ARG_REQUIRED is equivalent to a ':' getopt option, but NOT_REQUIRED could mean optional or not. That is, -d vs -d # vs -d [#]. Suggest dropping _value from the getter funcs for brevity and have bool return int instead of long (or callers may have to cast in some contexts). I think part of the runtime complexity is through the use of the ptbl container, which is more meant for dynamic data. It works, but then does make static initialization a problem. I'm going to play with an alternative container and will see what you think. Cheers! Sean ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
