Re: Re: Gengetopt 2.21 enhancement suggestions

J. David Bryan wrote:
> On 16 Oct 2007 at 23:23, Lorenzo Bettini wrote:
> 
>> you mean this way you can detect where the error is?
> 
> I think so.  "optopt" is set to the unrecognized option character, and 
> "optind" is set to the next argv index (so "optind - 1" should index to the 
> unrecognized option).  If I need more detailed error coverage, I can leave 
> "opterr" = 1.
> 
> In my specific application (that prompted the suggestion), I have to parse 
> the command line myself, as the syntax of one of the options cannot be 
> handled by gengetopt.  But instead of programming everything myself,  I'd 
> like gengetopt to handle everything except that special option.  In this 
> case, the "error" from the parser simply means that it has found the option 
> that I must parse from argv myself.  I don't want to print an error 
> message, because there is no error.  :-)
> 

OK :-)

> 
>> well, actually, when I was thinking about enums I was thinking about
>> ALSO storing values as enums....
> 
> In the original suggestion from last year, it was proposed to generate 
> enums instead of strings.  For backward compatibility, you thought that 
> keeping both representations was best.  I agree.
> 
> But I have proposed generating enums _or_ strings (or ints, floats, etc.), 
> depending on the user's choice.  Backward compatibility is guaranteed if 
> the user chooses strings (or chooses the default, which should be strings). 
>  If the user chooses enums, then enums should be all that are needed.  If 
> the user needs strings, he can choose strings.
> 
> So:
> 
>   option "rotate" r "Rotate clockwise" values="0","90","180","270"
> 
> ...would be the same as:
> 
>   option "rotate" r "Rotate clockwise" string values="0","90","180","270"
> 
> ...and would generate strings.  And:
> 
>   option "rotate" r "Rotate clockwise" enum values="0","90","180","270"
> 
> ...would generate enums.  No need to generate strings too, I think, because 
> I have explicitly said that I want enums.
> 

However, 90 would not be a valid enum (since it starts with a number) so 
enum values should still be generated in some modified way, e.g., 
enum_90 or ENUM_90, that was my main problem...

however, I'll work on this

cheers
	Lorenzo

-- 
Lorenzo Bettini, PhD in Computer Science, DSI, Univ. di Firenze
ICQ# lbetto, 16080134     (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com  http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net