[Top][All Lists]

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

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

From: Ken Hornstein
Subject: Re: [Nmh-workers] nmh internals: argument processing
Date: Tue, 08 Jan 2013 14:00:33 -0500

>> 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.

True, but ....

>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.

I'm trying to envision how this would work.  You can't have them part
of the same statement, because the enum and the elements of the
struct swit array need to be two seperate statements.  Is that possible
with the X() macro?  I'm not seeing it.

Also, I don't think we can have it in a central include file, since there
are some cases where there are two different struct swit arrays in the
same source code file.

>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.

True, but that's merely a style issue, not a requirement of the code.
I could see it being relaxed.


reply via email to

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