On Wed, Sep 18, 2013 at 10:41 PM, Christopher Sean Morrison <brl...@mac.com> wrote: > > 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
Roger. > 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 Okay. > 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. Is this okay: "bu_arg_unlabeled_value_arg"? > Question, though, why is it important that the bu_arg_value_t > first enum be an integral type? That was from trying to initialize the union part. From this link: http://www.velocityreviews.com/forums/t443667-intializing-struct-containing-an-union.html I read: <quote> >But if I understood what I read in the FAQ right, you can't initialize >the unions in C89, only in C99 with ``designated initializers''. More precisely, you can only initialize the *first* union member. </quote> Given that the struct has to be fixed, the integral type seemed to be the most likely to be used. > Also, is it possible to have an optional arg value? Yes, apparently (I haven't done detailed testing yet). It's a little confusing, as is the use of the bools I agree. From the TCLAP description of the ValueArg contructor: <quote> req - Whether the argument is required on the command line. value - The default value assigned to this argument if it is not present on the command line. <unquote> So I read that if the default value is NOT given then the arg needs a value, otherwise its value on the command line is optional. > 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 [#]. Exactly. Remember though I was trying to make the single struct fit ALL the constructors, that's why I like my new interface because I think it is a bit less confusing for the user. As far as the memory issue goes we could have a new bu_arg_exit function/macro that would clear memory before exiting. > Suggest dropping _value from the getter funcs for brevity Will do. > and have bool return int instead of long (or callers may > have to cast in some contexts). Roger. > 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. Yes, I would certainly like to go C++ for all! > I'm going to play with an alternative container and will see what you think. Cheers! -Tom ------------------------------------------------------------------------------ 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
