Pardon the difficulty in reading what should be in front of my face.  C
++0X refers to the n3000 draft for the rest of this post.

1) forward-declaration of enumerations, e.g.

enum test;

C++0X n3000 appears to allow forward declarations (as an opaque enum-
declaration; dcl.enum p3, in spite of dcl.enum p4)  C99 6.7.2.3p2
pretty clearly forbids, and a quick check against GCC 4.2.1 suggests
that forward-declared enum is rejected so:
* am I misreading the C++0X standard?
* if the above is no: is there a clear way to derive C++98 either
accepting, or rejecting, a forward-declared enumeration?

2) multiply defined enumerations, etc.

enum test2 {
   x_factor = 1
}

enum test2 {
   x_factor = 1
}

I'm basically clueless regarding both C++98 and C++0X regarding
citation.  However, GCC 4.2.1 rejects the above as a duplicate
definition, and C99 6.7.2.3p1 clearly forbids.
* Is there a clear way, in either C++98 or C++0X, to derive either
accepting or rejecting identical duplicate definitions of an
enumeration?

(Omission of C++03 is because I haven't purchased that yet.)

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Kenneth 'Bessarion' Boyd wrote:

> Pardon the difficulty in reading what should be in front of my face.  C
> ++0X refers to the n3000 draft for the rest of this post.
>
> 1) forward-declaration of enumerations, e.g.
>
> enum test;
>
> C++0X n3000 appears to allow forward declarations (as an opaque enum-
> declaration; dcl.enum p3, in spite of dcl.enum p4)  C99 6.7.2.3p2
> pretty clearly forbids, and a quick check against GCC 4.2.1 suggests
> that forward-declared enum is rejected so:
> * am I misreading the C++0X standard?
> * if the above is no: is there a clear way to derive C++98 either
> accepting, or rejecting, a forward-declared enumeration?
>
7.2/2:  An opaque-enum-declaration declaring an unscoped enumeration shall
not omit the enum-base.

> 2) multiply defined enumerations, etc.
>
> enum test2 {
>    x_factor = 1
> }
>
> enum test2 {
>    x_factor = 1
> }
>
> I'm basically clueless regarding both C++98 and C++0X regarding
> citation.  However, GCC 4.2.1 rejects the above as a duplicate
> definition, and C99 6.7.2.3p1 clearly forbids.
> * Is there a clear way, in either C++98 or C++0X, to derive either
> accepting or rejecting identical duplicate definitions of an
> enumeration?
>
> (Omission of C++03 is because I haven't purchased that yet.)
>
3.2/1: No translation unit shall contain more than one definition of any
variable, function, class type, enumeration type or template.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 22 Nov., 19:56, "Kenneth 'Bessarion' Boyd" <zaim...@zaimoni.com>
wrote:
> Pardon the difficulty in reading what should be in front of my face.  C
> ++0X refers to the n3000 draft for the rest of this post.
>
> 1) forward-declaration of enumerations, e.g.
>
> enum test;
>
> C++0X n3000 appears to allow forward declarations (as an opaque enum-
> declaration; dcl.enum p3, in spite of dcl.enum p4)

Just to be sure: Above declaration is ill-formed in C++0x. You
need to provide an /enum-base/ to make it well-formed, as in

enum test : int;

or you need to declare a scoped enum as in

enum class test; // int is implied as underlying type here

Now the compiler has the necessary information about the final
size of the enumeration without need to "see" the enumerator-list.

> C99 6.7.2.3p2
> pretty clearly forbids, and a quick check against GCC 4.2.1 suggests
> that forward-declared enum is rejected so:
> * am I misreading the C++0X standard?

I don't know, but your example above would not be supported.

> * if the above is no: is there a clear way to derive C++98 either
> accepting, or rejecting, a forward-declared enumeration?

I agree that C++ does not write it as clear as C99. You need to
combine wording from several different locations to get an
unambiguous argumentation base. In ISO/IEC 14882:1998(E)
we find the following:

a) [basic.def]/2 doesn't mention non-defining enum declarations:

"A declaration is a definition unless it declares a function without
specifying the function   s body (8.4), it contains the extern
specifier
(7.1.1) or a linkage-specification24)(7.5) and neither an initializer
nor a functionbody, it declares a static data member in a class
declaration (9.4), it is a class name declaration (9.1), or it is a
typedef declaration (7.1.3), a using-declaration (7.3.3), or a using-
directive (7.3.4)."

b) [dcl.type.elab] describes situations where an elaborated type-
specifier is the sole constituent of a declaration - none of these
listed cases in p. 1 does apply for enums. It is noteworthy to
emphasize that in C++0x also an elaborated type-specifier of
the form

enum ::opt nested-name-specifier_opt identifier

is not supported, because the size information is missing.

c) Just as a remark, [basic.scope.pdecl] did not list enums
at all until

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#417

was resolved. But this lack was a defect from 1998 on and should
not be an argument against non-defining enum declarations.

> 2) multiply defined enumerations, etc.
>
> enum test2 {
>    x_factor = 1
> }
>
> enum test2 {
>    x_factor = 1
> }
>
> I'm basically clueless regarding both C++98 and C++0X regarding
> citation.  However, GCC 4.2.1 rejects the above as a duplicate
> definition, and C99 6.7.2.3p1 clearly forbids.
> * Is there a clear way, in either C++98 or C++0X, to derive either
> accepting or rejecting identical duplicate definitions of an
> enumeration?

This is already clearly defined in C++98 as part of the One-Definition-
Rule,
see [basic.def.odr]/1:

"No translation unit shall contain more than one definition of any
variable,
function, class type, enumeration type or template."

HTH & Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Thanks to both of you (Johannes and Daniel).  Since the corrected
readings are pretty much the same I'll just reply here.

On Nov 23, 11:22 am, Daniel Kr=FCgler <daniel.krueg...@googlemail.com>
wrote:
> On 22 Nov., 19:56, "Kenneth 'Bessarion' Boyd" <zaim...@zaimoni.com>
> wrote:
>
> > Pardon the difficulty in reading what should be in front of my face.  C
> > ++0X refers to the n3000 draft for the rest of this post.
>
> > 1) forward-declaration of enumerations, e.g.
>
> > enum test;
>
> > C++0X n3000 appears to allow forward declarations (as an opaque enum-
> > declaration; dcl.enum p3, in spite of dcl.enum p4)
>
> Just to be sure: Above declaration is ill-formed in C++0x. You
> need to provide an /enum-base/ to make it well-formed, as in
>
> enum test : int;
>
> or you need to declare a scoped enum as in
>
> enum class test; // int is implied as underlying type here

Ok.  I take it that being well formed still runs afoul of [basic.def]/
2 and [dcl.type.elab]?

> ....

> > * if the above is no: is there a clear way to derive C++98 either
> > accepting, or rejecting, a forward-declared enumeration?
>
> I agree that C++ does not write it as clear as C99. You need to
> combine wording from several different locations to get an
> unambiguous argumentation base. In ISO/IEC 14882:1998(E)
> we find the following:
>
> a) [basic.def]/2 doesn't mention non-defining enum declarations:
>
> ....
>
> b) [dcl.type.elab] describes situations where an elaborated type-
> specifier is the sole constituent of a declaration - none of these
> listed cases in p. 1 does apply for enums. ....

> c)  ....

Ok.  That's clear enough.

> > 2) multiply defined enumerations, etc.

> ....

> This is already clearly defined in C++98 as part of the One-Definition-
> Rule,
> see [basic.def.odr]/1:
>
> "No translation unit shall contain more than one definition of any
> variable,
> function, class type, enumeration type or template."

Ok.  (Citation error for double-defined union/struct/class, in the
vaporware compiler motivating these questions, will be fixed on the
next SVN update.)


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Kenneth 'Bessarion' Boyd wrote:

> Thanks to both of you (Johannes and Daniel).  Since the corrected
> readings are pretty much the same I'll just reply here.
>
> On Nov 23, 11:22 am, Daniel Kr=FCgler <daniel.krueg...@googlemail.com>
> wrote:
>> On 22 Nov., 19:56, "Kenneth 'Bessarion' Boyd" <zaim...@zaimoni.com>
>> wrote:
>>
>> > Pardon the difficulty in reading what should be in front of my face.  C
>> > ++0X refers to the n3000 draft for the rest of this post.
>>
>> > 1) forward-declaration of enumerations, e.g.
>>
>> > enum test;
>>
>> > C++0X n3000 appears to allow forward declarations (as an opaque enum-
>> > declaration; dcl.enum p3, in spite of dcl.enum p4)
>>
>> Just to be sure: Above declaration is ill-formed in C++0x. You
>> need to provide an /enum-base/ to make it well-formed, as in
>>
>> enum test : int;
>>
>> or you need to declare a scoped enum as in
>>
>> enum class test; // int is implied as underlying type here
>
> Ok.  I take it that being well formed still runs afoul of [basic.def]/
> 2 and [dcl.type.elab]?
>

It doesn't, because "enum class test" is not an elaborated type specifier.
To refer to a previously declared scoped enumeration with an elaborated type
specifier, you just say "enum [some_scope_qualifier] identifier" as in "enum
test", without "class": The compiler looks it up and will see whether it's
scoped/uscoped.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Nov 24, 12:19 am, "Kenneth 'Bessarion' Boyd" <zaim...@zaimoni.com>
wrote:
> Thanks to both of you (Johannes and Daniel).  Since the corrected
> readings are pretty much the same I'll just reply here.
>
> On Nov 23, 11:22 am, Daniel Kr=FCgler <daniel.krueg...@googlemail.com>
> wrote:
>
>
>
> > On 22 Nov., 19:56, "Kenneth 'Bessarion' Boyd" <zaim...@zaimoni.com>
> > wrote:
>
> > > Pardon the difficulty in reading what should be in front of my face.  C
> > > ++0X refers to the n3000 draft for the rest of this post.
>
> > > 1) forward-declaration of enumerations, e.g.
>
> > > enum test;
>
> > > C++0X n3000 appears to allow forward declarations (as an opaque enum-
> > > declaration; dcl.enum p3, in spite of dcl.enum p4)
>
> > Just to be sure: Above declaration is ill-formed in C++0x. You
> > need to provide an /enum-base/ to make it well-formed, as in
>
> > enum test : int;
>
> > or you need to declare a scoped enum as in
>
> > enum class test; // int is implied as underlying type here
>
> Ok.  I take it that being well formed still runs afoul of [basic.def]/
> 2 and [dcl.type.elab]?

Sure, in C++0x the ODR hasn't changed regarding this part and
[dcl.type.elab] still excludes the grammar production

enum ::_opt nested-name-specifier_opt identifier

as a "sole constituent of a declaration".

HTH & Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]