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 "constructo r 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(M y_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<fla g>(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(M y_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