the range of enum

Discussion in 'C++' started by Vane, Jul 20, 2005.

  1. Vane

    Vane Guest

    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?
     
    Vane, Jul 20, 2005
    #1
    1. Advertising

  2. Vane

    Zorro Guest

    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

    http://www.zhmicro.com
    http://distributed-software.blogspot.com
     
    Zorro, Jul 20, 2005
    #2
    1. Advertising

  3. Vane

    Rolf Magnus Guest

    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.
     
    Rolf Magnus, Jul 20, 2005
    #3
  4. Vane

    Rolf Magnus Guest

    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;
     
    Rolf Magnus, Jul 20, 2005
    #4
  5. Vane

    Zorro Guest

    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.
     
    Zorro, Jul 20, 2005
    #5
  6. 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
     
    Jonathan Mcdougall, Jul 20, 2005
    #6
  7. Vane

    Zorro Guest

    > 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.
     
    Zorro, Jul 21, 2005
    #7
  8. Vane

    Rolf Magnus Guest

    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.
     
    Rolf Magnus, Jul 21, 2005
    #8
  9. Vane

    Zorro Guest

    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.
     
    Zorro, Jul 21, 2005
    #9
  10. 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
     
    Jonathan Mcdougall, Jul 21, 2005
    #10
  11. Vane

    Me Guest

    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
     
    Me, Jul 22, 2005
    #11
  12. Vane

    Zorro Guest

    > 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, Jul 22, 2005
    #12
  13. Vane

    Zorro Guest

    > A "constructor cast" does not exist.

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

    Regards,
    Z.
     
    Zorro, Jul 22, 2005
    #13
  14. Vane

    Zorro Guest

    > 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.
     
    Zorro, Jul 22, 2005
    #14
  15. 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
     
    Jonathan Mcdougall, Jul 31, 2005
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. -

    enum within an enum

    -, Jun 12, 2005, in forum: Java
    Replies:
    6
    Views:
    549
  2. Jerminia
    Replies:
    3
    Views:
    633
    Roedy Green
    Oct 7, 2005
  3. Ernst Murnleitner

    How to enum an enum?

    Ernst Murnleitner, Nov 12, 2003, in forum: C++
    Replies:
    5
    Views:
    471
    Rolf Magnus
    Nov 13, 2003
  4. mrhicks
    Replies:
    2
    Views:
    428
    Dave Thompson
    Jun 10, 2004
  5. Randy
    Replies:
    1
    Views:
    520
    David Harmon
    Jan 7, 2006
Loading...

Share This Page