the range of enum

[Vane]

According to <<C++ Programming Language>>:

enum flag { x = 1, y = 2, z = 4, e = 8 }; //range 0:15
...
flag f4 = flag(99); // undefined : 99 is not within the range of flag

But the following codes has result 99.

//--------------------------------------------------
#include "iostream"

int main(int argc, char* argv[])
{
enum flag{ x = 1, y = 2, z = 4, e = 8 };

flag f1 = flag( 99 );

std::cout<<f1<<std::endl;

return 0;
}

//----------------------------------------------------
Whether the compiler treats enum type as integral type? Then what's the
meaning of the range of enum?

[Rolf Magnus]

Vane wrote:

According to <<C++ Programming Language>>:

enum flag { x = 1, y = 2, z = 4, e = 8 }; //range 0:15
...
flag f4 = flag(99); // undefined : 99 is not within the range of flag

But the following codes has result 99.

"Undefined" means "the result can be anything". And this includes a
value of 99.

[Zorro]

This is an appropriate answer, as some compilers are implemented.
However, the compiler should have produced error at:

flag f4 = flag(99);

At this point, saying undefined means anything you do is OK, does not
seem justifiable.

Regards,
Dr. Z.
Chief Scientist
zo****@ZHMicro.com
http://www.zhmicro.com
http://distributed-software.blogspot.com

[Rolf Magnus]

Zorro wrote:

This is an appropriate answer, as some compilers are implemented.
However, the compiler should have produced error at:

flag f4 = flag(99);

No, it shouldn't. This is a cast, and casting an integer into an enum is
allowed. It would be different if it were:

flag f4 = 99;

[Zorro]

Well, it is a (constructor) cast. Let me try to expand on this a
little.

In actuality the compiler optimizes "flag f4 = flag(99)" and directly
initializes f4 with 99. Let us leave out optimization.

Then, "flag(99)" results in a temporary, call it T, which is
initialized with 99. At this point we have an error because the
compiler knows 99 is not a value of the type. Otherwise what is the use
of listing values for an enum?

At any rate, next the temporary T is assigned to f4 which is fine since
both are of the same type.

Now, you agree that "flag f4 = 99" is an error. Then how is the
creation of T permissible?

Regards,
Z.

[Jonathan Mcdougall]

Zorro wrote:

Well, it is a (constructor) cast. Let me try to expand on this a
little.
A "constructor cast" does not exist.
In actuality the compiler optimizes "flag f4 = flag(99)" and directly
initializes f4 with 99.
Who said that?
Let us leave out optimization.
Good.
Then, "flag(99)" results in a temporary, call it T, which is
initialized with 99. At this point we have an error because the
compiler knows 99 is not a value of the type. Otherwise what is the use
of listing values for an enum?

At any rate, next the temporary T is assigned to f4 which is fine since
both are of the same type.

Now, you agree that "flag f4 = 99" is an error. Then how is the
creation of T permissible?

Because the language says it's undefined behavior, not an illegal
construct.
Jonathan

[Zorro]

> Because the language says it's undefined behavior, not an illegal

construct.

That is all I am replying to.

Consider a switch statement that uses an enum value out of range, or
one that does not use them all. In these cases you will get a warning.
So the compiler does know about the range.

Now consider declaring something where the initializer is not of the
right type. Then you will get an error.

Now, in our case the initializer is not of the right type because the
value is not in the list. Just as the compiler can check that for a
switch statement, it can check it here too.

If that is the standard, someone will probably tell us. All I am saying
is that, according to general perception of C++ being strongly typed,
and the availability of information at the point of declaration, that
is an error. If it were impossible to determine, then the term
undefined would be appropriate.

Nevertheless, if the language identifies this error as undefined, so be
it.

Of course the statement is not illegal. But are all (syntactically)
legal statements permissible?

Regards,
Z.

[Rolf Magnus]

Zorro wrote:

Because the language says it's undefined behavior, not an illegal
construct.
That is all I am replying to.

Consider a switch statement that uses an enum value out of range, or
one that does not use them all. In these cases you will get a warning.
So the compiler does know about the range.

Yes.
Now consider declaring something where the initializer is not of the
right type. Then you will get an error.
If there is no suitable conversion, yes.
Now, in our case the initializer is not of the right type because the
value is not in the list.
Right, that's why you get an error when writing:

flag f4 = 99;
Just as the compiler can check that for a switch statement, it can check
it here too.
Well, if you write:

flag f4 = flag(99);

you use a cast, which explicitly says to the compiler: "I know that it
doesn't fit, but I know what I'm doing, so shut up and do it anyway."
This transfers the responsibility to you.

The bottom line: Use a cast only if you are really sure you know it's the
right thing to do.
If that is the standard, someone will probably tell us. All I am saying
is that, according to general perception of C++ being strongly typed,
and the availability of information at the point of declaration, that
is an error.
With the "right" cast, you can do almost any conversion you like, even those
that might not make sense.
If it were impossible to determine, then the term undefined would be
appropriate.

It is possible, but a cast was used to explicitly switch that determination
off.

[Zorro]

This is very well put. I have a different opinion, not necessarily
better than yours.

The notation flag(99) is indeed referred to as cast (copied from ADA).
However, in C++ that is also a constructor and is expected to produce
an instance of its type. In ADA something like int(x) returns a literal
value, not an object.

In C++, I think, "int i = int(5);" is the same as:

My_class_type X = My_class_type(a, b, c);

which is equivalent to:

My_class_type X(a, b, c);

However, the semantics of the first version (in my opinion) is that the
right hand side is creating a temporary instance, just like when we use
it as argument to a call, like this:

some_function(My_class_type(a, b, c));

Several compilers will generate error if the pass is by reference
because the instance being created for the argument is a temporary (GNU
and Metrowerks do that).

So, perhaps the notation flag(99) has two different meanings in C++.

Regards,
Z.

[Jonathan Mcdougall]

Zorro wrote:

This is very well put. I have a different opinion, not necessarily
better than yours.
Please, quote the message you are answering to.
The notation flag(99) is indeed referred to as cast (copied from ADA).
This is not a cast.

flag f = static_cast<flag>(99); // cast
flag f = flag(99); // copy-construction
However, in C++ that is also a constructor and is expected to produce
an instance of its type. In ADA something like int(x) returns a literal
value, not an object.
What does ADA have to do with this?
In C++, I think, "int i = int(5);" is the same as:

My_class_type X = My_class_type(a, b, c);
If you mean that it calls constructor, yes.
which is equivalent to:

My_class_type X(a, b, c);
Not necessarily. The first may call the copy-constructor and the second
calls one of the constructors with arguements.
However, the semantics of the first version (in my opinion) is that the
right hand side is creating a temporary instance, just like when we use
it as argument to a call, like this:

some_function(My_class_type(a, b, c));
Yes.
Several compilers will generate error if the pass is by reference
because the instance being created for the argument is a temporary (GNU
and Metrowerks do that).
It is illegal to bound a non-const reference to a rvalue, if that's
what you mean. All compilers should give an error.
So, perhaps the notation flag(99) has two different meanings in C++.

What meanings?
Jonathan

[Me]

Vane wrote:

According to <<C++ Programming Language>>:

enum flag { x = 1, y = 2, z = 4, e = 8 }; //range 0:15
...
flag f4 = flag(99); // undefined : 99 is not within the range of flag

It's not undefined:

7.2/9 "An expression of arithmetic or enumeration type can be converted
to an enumeration type explicitly. The value is unchanged if it is in
the range of enumeration values of the enumeration type; otherwise the
resulting enumeration value is unspecified."
But the following codes has result 99.
It is allowed to result in 99, but it isn't required to.
//--------------------------------------------------
#include "iostream"

int main(int argc, char* argv[])
{
enum flag{ x = 1, y = 2, z = 4, e = 8 };

flag f1 = flag( 99 );

std::cout<<f1<<std::endl;

return 0;
}

//----------------------------------------------------
Whether the compiler treats enum type as integral type?
I don't understand what you mean. enums aren't considered integral (or
arithmetic) type but due to very similar type conversion semantics as
bool (which is considered an integral type), you can, for the most
part, treat enum as if it were a signed integral type (since you have
no guarantee about what happens if it is out of range).
Then what's the meaning of the range of enum?

The meaning of the range of an enum tells you what is allowed in a
standard conforming program (i.e. a program guaranteed to work on all
implementations of C++ since it doesn't rely on undefined, unspecified,
or implementation defined behavior or implementation limits).
Specifically:

- you can cast a integer in the range 0 to 15 to flag and and back and
have it still result in the same value
- 4 is the minimum bit-field width guaranteed to represent all of the
values of flag

[Zorro]

> Please, quote the message you are answering to.

I was referring to your entire post. However, you are right and I must
have been more specific.
My apologies. Also, I will keep that in mind in the future.

Regards,
Z.

[Zorro]

> A "constructor cast" does not exist.

I wonder what is the purpose of "explicit" specifier (with regard to
coercion)?

Regards,
Z.

[Zorro]

> This is not a cast.

So, what is "int(2.3)" ? You realize this is a built-in type and does
not produce an object (lvalue).

What does ADA have to do with this?
The above answer should help.
Not necessarily. The first may call the copy-constructor and the second
calls one of the constructors with arguements.
The equivalence is in the semantics.
It is illegal to bound a non-const reference to a rvalue, if that's
what you mean. All compilers should give an error.
Try VC++.
What meanings?

Is int(5) a literal, or an object? Now apply your conclusion to
flag(99). Is flag treated as a built-in, or a user-defined type?

Regards,
Z.

[Jonathan Mcdougall]

Zorro wrote:

This is not a cast.
So, what is "int(2.3)" ?

An rvalue, sometimes called a "temporary object", which is wrong
because it is not an object. It is produces by what is called an
"Explicit type conversion (functional notation)" in the standard. It is
*not* a cast.
You realize this is a built-in type and does
not produce an object (lvalue).
Yes I do.

What does ADA have to do with this?

The above answer should help.

Hmm.. unfortunately no.

Not necessarily. The first may call the copy-constructor and the second
calls one of the constructors with arguements.

The equivalence is in the semantics.

Again, not necessarily. The copy-constructor and constructor with
arguments may behave differently.

It is illegal to bound a non-const reference to a rvalue, if that's
what you mean. All compilers should give an error.

Try VC++.

I said: "All compilers should give an error".

What meanings?

Is int(5) a literal, or an object?

Neither. It is an rvalue.
Now apply your conclusion to
flag(99).
Again, it is an rvalue.
Is flag treated as a built-in, or a user-defined type?

An enum is a user-defined type if that's your question, so it is
treated as such.

int(1) and flag(99) are both rvalues. Semantically, they do the same
thing, except that the second one is unspecified (but not undefined,
thanks to Me for the correction; it never occured to me that having Me
as a name could make a funny quote; whatever).
Jonathan