Is 'enum Colour : int { red, green, blue };' legal?

[Jorn Ronnow]

I'm a bit confused here, since the help in M$ Visual Studio 2005 states the
syntax for enum as:

enum [tag] [: type] {enum-list} [declarator];

So, it would be possible to write:

enum Protocol_t : unsigned char { ICMP = 1, TCP = 6, UDP = 17 };
struct IPHeader {
// ...
Protocol_t Protocol;
// ...
};

It sounds like an M$ specific extension to me, but it's not listed as such
in VS2005's help section "Microsoft Extensions to C and C++". On the other
hand, it's not included in Schildt's "C++: The Complete Reference" (4th ed,
2003).

cul8r
/Jörn

 

[Jonathan Mcdougall]

I'm a bit confused here, since the help in M$ Visual Studio 2005 states the
syntax for enum as:

enum [tag] [: type] {enum-list} [declarator];

The [: type] part is an extension. The C++ standard states

7.2§1 [...] enum identifier(opt) { enumerator-list(opt) }

So, it would be possible to write:

enum Protocol_t : unsigned char { ICMP = 1, TCP = 6, UDP = 17 };
struct IPHeader {
// ...
Protocol_t Protocol;
// ...
};

It sounds like an M$ specific extension to me, but it's not listed as such
in VS2005's help section "Microsoft Extensions to C and C++".

That's unfortunate, really. I suggest you notify them, even if it may
be to no avail.

On the other
hand, it's not included in Schildt's "C++: The Complete Reference" (4th ed,
2003).

You may read http://tinyurl.com/jyomc for information on this book.


Jonathan

 

[Victor Bazarov]

I'm a bit confused here, since the help in M$ Visual Studio 2005
states the syntax for enum as:

enum [tag] [: type] {enum-list} [declarator];

So, it would be possible to write:

enum Protocol_t : unsigned char { ICMP = 1, TCP = 6, UDP = 17 };
struct IPHeader {
// ...
Protocol_t Protocol;
// ...
};

It sounds like an M$ specific extension to me, but it's not listed as
such in VS2005's help section "Microsoft Extensions to C and C++". On
the other hand, it's not included in Schildt's "C++: The Complete
Reference" (4th ed, 2003).

First and foremost, good that you asked here. At least knowledgeable
people will read and answer. AFAIK, the "[: type]" is non-standard.

Second, although it seems that in this case Schildt shows agreement
with what's considered correct in c.l.c++, in many cases Schildt's books
are not recommended, see www.accu.org. You've been warned.

V

 

[Bo Persson]

I'm a bit confused here, since the help in M$ Visual Studio 2005
states the syntax for enum as:

enum [tag] [: type] {enum-list} [declarator];

So, it would be possible to write:

enum Protocol_t : unsigned char { ICMP = 1, TCP = 6, UDP = 17 };
struct IPHeader {
// ...
Protocol_t Protocol;
// ...
};

It sounds like an M$ specific extension to me, but it's not listed
as
such in VS2005's help section "Microsoft Extensions to C and C++".
On
the other hand, it's not included in Schildt's "C++: The Complete
Reference" (4th ed, 2003).

First and foremost, good that you asked here. At least
knowledgeable
people will read and answer. AFAIK, the "[: type]" is non-standard.

But it is *a* standard, ECMA-372 The C++/CLI language

http://www.ecma-international.org/publications/standards/Ecma-372.htm


Confusing, isn't it?

Bo Persson

 

[phlip]

But it is *a* standard, ECMA-372 The C++/CLI language

http://www.ecma-international.org/publications/standards/Ecma-372.htm

Confusing, isn't it?

A web site with .org on it does not a Standard (or a non-profit) make!

 

[Victor Bazarov]

I'm a bit confused here, since the help in M$ Visual Studio 2005
states the syntax for enum as:

enum [tag] [: type] {enum-list} [declarator];

So, it would be possible to write:

enum Protocol_t : unsigned char { ICMP = 1, TCP = 6, UDP = 17 };
struct IPHeader {
// ...
Protocol_t Protocol;
// ...
};

It sounds like an M$ specific extension to me, but it's not listed
as
such in VS2005's help section "Microsoft Extensions to C and C++".
On
the other hand, it's not included in Schildt's "C++: The Complete
Reference" (4th ed, 2003).

First and foremost, good that you asked here. At least
knowledgeable
people will read and answer. AFAIK, the "[: type]" is non-standard.

But it is *a* standard, ECMA-372 The C++/CLI language

http://www.ecma-international.org/publications/standards/Ecma-372.htm


Confusing, isn't it?

The only Standard relevant _here_ is ISO/IEC 14992:2003. *It* makes
no reference to the one you named ("ECMA-372", whatever that is). No
confusion here, AFAICT.

V

 

[Markus Schoder]

The only Standard relevant _here_ is ISO/IEC 14992:2003. *It* makes
no reference to the one you named ("ECMA-372", whatever that is). No
confusion here, AFAICT.

I really have to upgrade I am still on ISO/IEC 14882:2003

 

[Jorn Ronnow]

That's unfortunate, really. I suggest you notify them, even if it may
be to no avail.

It seems I'm better off trusting my instincts than the M$ list of
extensions. The mere presence of extensions is a bit of a perversion, IMHO,
but that's another debate.

You may read http://tinyurl.com/jyomc for information on this book.

That saved me from wasting my time, thanks!

cul8r
/Jörn

 

[phlip]

The mere presence of extensions is a bit of a perversion, IMHO,
but that's another debate.

Sometimes an extension intends to lead developers into a trap from which
they cannot return to a competitor's tools.

However, always remember these extensions are not free to add, and the
enum [:type] extension looks too feeble to return its value by trapping
programmers.

One big problem with the Standard enum system is it's only
defined as having "at least enough bits" to hold all its values. This
makes it worse than useless in every situation where you need an enum to
fit and pad reliably. The [:type] extension makes enums reliable enough to
compete with our favorite keyword, #define, in more situations...

Please discuss union-ing an enum with a type of known size here ->[ ].

Please write legibly!

 

[Rolf Magnus]

The mere presence of extensions is a bit of a perversion, IMHO,
but that's another debate.

Sometimes an extension intends to lead developers into a trap from which
they cannot return to a competitor's tools.

However, always remember these extensions are not free to add, and the
enum [:type] extension looks too feeble to return its value by trapping
programmers.

One big problem with the Standard enum system is it's only
defined as having "at least enough bits" to hold all its values. This
makes it worse than useless in every situation where you need an enum to
fit and pad reliably.

Actually, I never needed an enum to "fit and pad reliably". Btw: according
to what you say, all the built-in types are also worse than useless,
because they all just have "at least enough bits" to support a defined
minimum range. Adding that [:type] thing buys you nothing, because you are
still relying on assumtions about the sizes of those types.

The [:type] extension makes enums reliable enough to
compete with our favorite keyword, #define, in more situations...

With #define, you don't define variables.

Please discuss union-ing an enum with a type of known size here ->[ ].

I guess you're joking?

 

[Kaz Kylheku]

It sounds like an M$ specific extension to me, but it's not listed as such
in VS2005's help section "Microsoft Extensions to C and C++".

That's what you get when you get your language definition from the
vendor documentation that came with your compiler.

C++ has an ANSI standard that you can download quite cheaply. (Actually
if you Google around, you can easily find a free PDF copy).

On the other hand, it's not included in Schildt's "C++: The Complete Reference"
(4th ed, 2003).

Hahaha. Google for "bullschildt".

 

[phlip]

Hahaha. Google for "bullschildt".

This newsgroup's Special Need to bust on H. Schildt even extends to when
he correctly omits a non-Standard feature.

 

[phlip]

Actually, I never needed an enum to "fit and pad reliably". Btw: according
to what you say, all the built-in types are also worse than useless,
because they all just have "at least enough bits" to support a defined
minimum range. Adding that [:type] thing buys you nothing, because you are
still relying on assumtions about the sizes of those types.

Built-in types can't change their bit requirements when you put one
more of their values into use.

 

[Bo Persson]

The mere presence of extensions is a bit of a perversion, IMHO,
but that's another debate.

Sometimes an extension intends to lead developers into a trap from
which
they cannot return to a competitor's tools.

However, always remember these extensions are not free to add, and
the
enum [:type] extension looks too feeble to return its value by
trapping
programmers.

One big problem with the Standard enum system is it's only
defined as having "at least enough bits" to hold all its values.
This
makes it worse than useless in every situation where you need an
enum to
fit and pad reliably.

Actually, I never needed an enum to "fit and pad reliably". Btw:
according
to what you say, all the built-in types are also worse than useless,
because they all just have "at least enough bits" to support a
defined
minimum range. Adding that [:type] thing buys you nothing, because
you are
still relying on assumtions about the sizes of those types.

The [:type] works for the other C++ language, because they have
defined the sizes for the integer types as well.


In real C++ you can set the "enough bits", by adding a dummy element
to the enum

enum { one, two, three, enough_bits = MAX_INT };


That works just as well (or just as bad) as

enum:int {one, two, three};


Bo Persson