RE: [sv-bc] 4.10.4 "Enumerated types in numerical expressions" - unclearness

Shalom,

 

My comments are interspersed below (in blue).

 

            Arturo

 

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Tuesday, November 01, 2005 2:40 AM
To: Steven Sharp; sv-bc@eda.org
Subject: RE: [sv-bc] 4.10.4 "Enumerated types in numerical expressions"
- unclearness

 

So what you and Dave seem to be saying is that the next() method

increments the enum value by 1 and then casts it back to the enum type.

 

No. That's not what it's supposed to do.

The next() method returns the next positional member, regardless of 

whether the members are consecutive or not. As you describe below.

 

This interpretation is certainly not clear from the text.

I had interpreted the text to mean that next() goes to the next member

in the list of members. Otherwise, why not simply say that it increments

the value, as I wrote above? Especially as the description of next()

immediately follows the descriptions of first() and last(), which

likewise refer to order in the list, as opposed to maximum and minimum

values.

 

Assuming that I interpret you correctly, that still leaves some open

questions.

 

It means for example, that the example in 4.10.4.7, of how to display

the name and values of all the members of an enumeration, is not

general, as is implied. It would only work if indeed each member has a

value incremented by 1 from the member preceding it in the list.

 

            Evidently, the example is correct; the interpretation is
wrong.

 

Also, you wrote,

" And if you haven't

>explicitly

>defined an enum member with an all-X value (which you generally

>won't),

>subsequent next() calls will continue to produce X"

 

It would seem to me that this will occur even if you have defined an

enum member with an X value. Incrementing X by 1 will still give you X.

So if you start from X, next() will leave you stuck there. And if you

start from a non-X value, next() will never bring you to the X value.

 

            Next() yields the next positional member (with wrap-around),
not

            the next numerical value.

 

By the way, I can declare a net as an enum, can't I? In that case, its

default initial value would be Z, not X, right?

 

 

Another question is about what is written is that "A wrap to the start

of the enumeration occurs when the end of the enumeration is reached."

So what happens if the last member in the enumeration list is not the

maximum value in the list?

Similarly, prev() mentions "when the start of the enumeration is

reached".

 

            Similarly, the values of enum members do not need to be
declared

in increasing order. The next() and previous() methods return the

next or previous positional values.

 

Finally, I want to go back to one of my previous questions.

 

4.10 says, "If an automatically incremented value is assigned elsewhere

in the same enumeration, this shall be a syntax error."

 

And 4.10.3 says, "Both the enumeration names and their integer values

must be unique." It is unclear what "their integer values must be

unique" means. It could mean that I may not assign two different values

to the same name, as it says explicitly two sentences later, or it could

mean that I may not assign the same value to two different enumeration

names. It says, "It is an error ... to set a value to the same

auto-incremented value," which is the same as quoted above in 4.10.

 

Perhaps some wordsmithing would help. But, the intent of unique is:

*         No two members of an enum shall have the same name

*         No two members of an enum shall have the same (numerical)
value

And, I agree that it is not a syntax error, but a compiler error.

 

But does this mean it is allowed to assign the same value twice

explicitly? If so, what would name() give me in this case?

 

            I believe doing so would violate both points above. For
example:

                        enum { foo = 1, foo = 1 } v;

            - Two members have the name: foo 

            - Two members have the same value: 1

 

Thanks,

Shalom

 

 

>>I don't know how to reconcile these. What is the case being

>described,

>>that "the given value is not a member of the enumeration"?

> 

>Despite the claim of "strong typing" in the LRM, there are a

>number of

>ways that an enum object can get a value that is not a member

>of the

>enumeration.  For example, you can explicitly define an enum

>whose

>numeric values are all even numbers, and then use a cast to

>assign an

>odd number to it.  Or you can define a int enum with 10

>members, which

>get assigned numbers 0-9, put it in a union with an ordinary

>int, and

>assign 100 to the int, which puts 100 into the enum int also.

> 

>Then if you invoke the next() method, the value being given to

>the

>method is not a member of the enumeration.  This LRM statement

>then

>says that the result of next() will be the default initial

>value for

>the enumeration.  This is X for a 4-state enum, which is what

>you

>would expect for an undefined operation.  And if you haven't

>explicitly

>defined an enum member with an all-X value (which you generally

>won't),

>subsequent next() calls will continue to produce X.