Quick question, what if this situation is encountered but the enums being autoincremented go up to 11? Will it skip and make the next one 13?
.Seth
> redef enum foo += {
> BAR_E, # value will be 12
> BAR_F = 5, # value will be 5
> BAR_G, # value will be 6
> };Quick question, what if this situation is encountered but the enums being autoincremented go up to 11? Will it skip and make the next one 13?
I'm having a hard time seeing why one would want autoincrement once an
explicit value is used, and it strikes me as buggy. My view is that either
*all* enums are defined with = X (and it's an error to define two with the
same value of X), or they're all implicit/autoincrement.
Vern
I think I don't understand the question.
BAR_E is autoincremented to 12, because BAR_D was 11.
If the autoincrement hits a number that has been defined previously, it
will generate a (parse) error and let you know.
Example:
{ A = 10,
B = 8,
C, # implicit 9
D, # would be implicit 10. ERROR. 10 already exists
}
A this version would work.
{ B=8, A=10, C, D }
cu
Gregor
I guess the only legitimate reason is to provide a seed value for the
following auto-increment values.
But I agree, that mixing them freely is a bad idea.
E.g.,
{
A = 100,
B,
C,
D,
......
}
Should I change it so that you can't mix auto-increment and explicit
assignments?
cu
Gregor
I guess the only legitimate reason is to provide a seed value for the
following auto-increment values.
Yeah, though for our purposes that still strikes me as buggy. Seems we'll
only want an enum to have a particular value if there's a network protocol
that associates names with values, and we want to mirror it. For those,
it seems safer to explicitly mirror its values rather than implicitly
mirroring them. Perhaps we can later add an exception (a single initial
seed is okay), but for now I think we should go with no mixing of
auto-increment & explicit.
Vern