nmh-workers
[Top] [All Lists]

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

2013-01-07 20:37:32
If the new struct member is always going to run from 0 without gaps, I
assume so since the current return value is an index into switches, then
it needn't be there?

Well, it doesn't HAVE to be, that's just the way it's implemented now.
Why keep it being an index when it doesn't have to be?

Continue to return the index.  Then just have the
enum instead of the #defines to remove the need to maintain the values.

I only think that's marginally easier ... I mean, if I want to know which
enum corresponds to a particular option, I'd have to count it out by hand,
the kind of tedious thing I'd rather leave to a computer.  Also, if I want
to rearrange options to make their groupings more logical (they're kind of
a mess right now) I'd have to reorder the enum list.

(Though with vim's Ctrl-A in normal, AKA command, mode I don't find it
much of a pain.)

Hrm.  AFAICT that just auto-increments the number under the cursor;
how does that help?

Lyndon writes:

The advantage is having symbolic values in the source debugger rather
than opaque translations from cpp.  I'm all in favour of this. It's a
godsend when you're tracing code.

I think in this case it won't help so much; AFAIK we can't declare
struct swit as taking a particular enum, and we can't declare smatch()
as returning an enum either (unless we want to collect all options into
one header file and have one super-enum which has them all; I think
that would be a mess).  Unless I'm missing something about how enums
work, which is possible.  Given those issues, I suspect the compiler
won't know that you're dealing with an enum and will just see it as int.
You can always cast it when you're in the debugger to see the symbolic
value, of course.

--Ken

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>