[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] nmh internals: argument processing

From: Ralph Corderoy
Subject: Re: [Nmh-workers] nmh internals: argument processing
Date: Tue, 08 Jan 2013 16:20:33 +0000

Hi Ken,

> I'm not sure that helps in this situation here, though.  We have three
> distinct bits of information that need to be matched up: the option
> name, the minimum abbreviation length, and the value that needs to be
> returned.  I'm not sure:
>       X("noaudit", 0, NAUDSW)
> is better than:
>       { "noaudit", 0, NAUDSW },

That's missing out the duplication needed by the enum definition in the
second part.

With X(), returning the index remains sufficient because the enum will
always match the array so there's no need to also store the index in the
struct.  The two expansions of X(), enum and array, could be in a
central #include.

Without X(), you have the chore of keeping the enum and array in the
same order for source-neatness even though the code doesn't need it
because it's returning the new struct member.

I'm easy either way, just presenting the pros and cons.

Cheers, Ralph.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]