In article <4p9he9$mdl@engnews1.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve
Clamage) writes:

|> In article 7rm@hasle.sn.no, froden@interlink.no (Frode Nilsen) writes:
|> >Could someone explain what is the rules for automatic initalization of
|> >enums. They are integral types and should be initalized the same way
|> >as an int. But with my compiler this doesn't seem to work (BC++ 5.0).
|> >
|> >If I have this lines of code
|> >
|> >enum colors { red, blue, green };
|> >
|> >colors somecolor;
|> >
|> >What shall the value of somecolor be, or is it undefined? Please
|> >direct me to the correct part of the Draft C++ standard.
|> >
|> >And if the enum is like this
|> >
|> >enum colors { red = -1, blue, green };
|> >
|> >What is the default value then?

|> Section 8.5 "Initializers" [dcl.init] says that static objects lacking
|> an initializer are zero-initialized. For scalar types, zero-initialization
|> means they get the value zero.

|> In C++ (unlike C), enums can have well-defined values other than the
|> explicit enumerator values.

I just think that C++ makes this more explicit.  In C, "Each enumerated
type shall be compatible with an integer type..."  This would seem to
imply that other well-defined values can exist, although it is not
really defined which ones they are.  (At the very least, all integer
types must support the range 0..127, so at least all of these would be
legal.)

|> An enum can have any value which is
|> representable in the number of bits required to represent the entire
|> range of all its enumerator values (loosely speaking -- the draft is more
|> precise). In particular, an object of ANY enum type can take on the value zero.

|> Thus, "somecolor" (assuming it is static and not automatic) gets the value
|> zero, which corresponds to "red" in the first example, and does not correspond
|> to any enumerator in the second example.

An interesting variation concerning the C++ standard:  in C++ (unlike
C), enumerators have the type of the enumeration, and there is no
implicit conversion from int to this type.  So consider:

    enum X { a = 1 , b = 2 } ;
    static X x ;

According the the DWP, "if T is a scalar type, the storage is set to the
value of 0 (zero) converted to T."  I presume that explicit conversions
are allowed here, since otherwise, the declaration of a static X would
be illegal.

I actually find it curious that:

    enum X { ... } ;
    enum X          x = 200 ;

The second statement is legal in C, not in C++.  However, the semantics
of the second statement are not really well defined in C, add the cast
to make it legal in C++, and they are.  (The word curious above is not
meant to be disparaging, but simply to call attention to the oddity of
the situation.)
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Could someone explain what is the rules for automatic initalization of
enums. They are integral types and should be initalized the same way
as an int. But with my compiler this doesn't seem to work (BC++ 5.0).

If I have this lines of code

enum colors { red, blue, green };

colors somecolor;

What shall the value of somecolor be, or is it undefined? Please
direct me to the correct part of the Draft C++ standard.

And if the enum is like this

enum colors { red = -1, blue, green };

What is the default value then?


Frode
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <4p9he9$mdl@engnews1.Eng.Sun.COM>,
   clamage@Eng.Sun.COM (Steve Clamage) wrote:
[Snip]
>>
>>enum colors { red = -1, blue, green };
>>
[Snip]
>Thus, "somecolor" (assuming it is static and not automatic) gets the value
>zero, which corresponds to "red" in the first example, and does not
correspond
>to any enumerator in the second example.

Steve,

Wouldn't the value of blue in the example above be zero? In that case,
shouldn't a statically allocated colors enumerator without an initializer have
the value blue?

Regards,


Torsten Hoff
thoff@symantec.com

(The views and opinions expressed are my own, and
should not be construed as representing those of
Symantec Corporation)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article 7rm@hasle.sn.no, froden@interlink.no (Frode Nilsen) writes:
>Could someone explain what is the rules for automatic initalization of
>enums. They are integral types and should be initalized the same way
>as an int. But with my compiler this doesn't seem to work (BC++ 5.0).
>
>If I have this lines of code
>
>enum colors { red, blue, green };
>
>colors somecolor;
>
>What shall the value of somecolor be, or is it undefined? Please
>direct me to the correct part of the Draft C++ standard.
>
>And if the enum is like this
>
>enum colors { red = -1, blue, green };
>
>What is the default value then?

Section 8.5 "Initializers" [dcl.init] says that static objects lacking
an initializer are zero-initialized. For scalar types, zero-initialization
means they get the value zero.

In C++ (unlike C), enums can have well-defined values other than the
explicit enumerator values. An enum can have any value which is
representable in the number of bits required to represent the entire
range of all its enumerator values (loosely speaking -- the draft is more
precise). In particular, an object of ANY enum type can take on the value zero.

Thus, "somecolor" (assuming it is static and not automatic) gets the value
zero, which corresponds to "red" in the first example, and does not correspond
to any enumerator in the second example.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article 97a@symiserver2.symantec.com, thoff@symantec.com (Torsten Hoff) writes:
>In article <4p9he9$mdl@engnews1.Eng.Sun.COM>,
>   clamage@Eng.Sun.COM (Steve Clamage) wrote:
>[Snip]
>>>
>>>enum colors { red = -1, blue, green };
>>>
>[Snip]
>>Thus, "somecolor" (assuming it is static and not automatic) gets the value
>>zero, which corresponds to "red" in the first example, and does not
>correspond
>>to any enumerator in the second example.
>
>Wouldn't the value of blue in the example above be zero? In that case,
>shouldn't a statically allocated colors enumerator without an initializer have
>the value blue?

Oops. Yes, of course. A case like
 enum colors { red=1, blue=2, green=3 };
would still be valid, and "somecolor" would have a zero value.

---
Steve Clamage, stephen.clamage@eng.sun.com




[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]