Ravikant Iyer <bom@slip.net> writes:

|>  Incidently MSVC 4.2 would complain when trying to use enums in cout
|>  expressions.. The error was that the call to ostream::operator << is
|>  ambiguous because it was overloaded for int, unsigned int , long etc etc...
|>  so one was forced to write cout << int(SomeEnumVal) ; or what ever
|>  the type u wanted it converted to.. looks like they have still not got this
|>  one right..

So what aren't they getting right?  As far as I can see, "cout <<
someEnumVal" is ambiguous.  The overloads are required by the draft
standard (and have been in every version of iostream.h that I've used).

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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                             ]

James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:

>
> Ravikant Iyer <bom@slip.net> writes:
>
>>  Incidently MSVC 4.2 would complain when trying to use enums in cout
>>  expressions.. The error was that the call to ostream::operator << is
>>  ambiguous because it was overloaded for int, unsigned int , long etc etc...
>>  so one was forced to write cout << int(SomeEnumVal) ; or what ever
>>  the type u wanted it converted to.. looks like they have still not got this
>>  one right..
>
> So what aren't they getting right?  As far as I can see, "cout <<
> someEnumVal" is ambiguous.
Why should the call be ambiguous?? Assuming there is no exact match for a
given enum type then applying implicit conversions to the argument the
enum should be converted to the proper type.. to determine the proper
type the following rule from CD2 should be used

4.5  Integral promotions [conv.prom] - para 2
2 An rvalue of type wchar_t (_basic.fundamental_) or an enumeration type
  (_dcl.enum_) can be converted to an rvalue of the first of the follow-
  ing types that can represent all the values of  its  underlying  type:
  int, unsigned int, long, or unsigned long.

The compiler should know what internal type it used to represent the
enum and should use it to resolve which operator << to call..

so unless I am missing something..

enum bigEnum {bigVal = LONG_MAX};
enum smallEnum {smallVal = INT_MAX};

void foo ()
{
   cout << bigVal << endl; // should call operator << (long)
   cout << smallVal << endl; // should call operator << (int)
}

gcc 2.7.2 calls the int version no matter what the value of the enum is
which is ok because on my platform sizeof(int) == sizeof(long)


>The overloads are required by the draft
> standard (and have been in every version of iostream.h that I've used).
>

I wasnt complaining about that :-) i should have been more clear

cheers
-bom
---
[ 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                             ]

The Bomm mann <bom@slip.net> writes:

|>  James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
|>
|>  >
|>  > Ravikant Iyer <bom@slip.net> writes:
|>  >
|>  >>  Incidently MSVC 4.2 would complain when trying to use enums in cout
|>  >>  expressions.. The error was that the call to ostream::operator << is
|>  >>  ambiguous because it was overloaded for int, unsigned int , long etc etc...
|>  >>  so one was forced to write cout << int(SomeEnumVal) ; or what ever
|>  >>  the type u wanted it converted to.. looks like they have still not got this
|>  >>  one right..
|>  >
|>  > So what aren't they getting right?  As far as I can see, "cout <<
|>  > someEnumVal" is ambiguous.
|>  Why should the call be ambiguous?? Assuming there is no exact match for a
|>  given enum type then applying implicit conversions to the argument the
|>  enum should be converted to the proper type.. to determine the proper
|>  type the following rule from CD2 should be used
|>
|>  4.5  Integral promotions [conv.prom] - para 2
|>  2 An rvalue of type wchar_t (_basic.fundamental_) or an enumeration type
|>    (_dcl.enum_) can be converted to an rvalue of the first of the follow-
|>    ing types that can represent all the values of  its  underlying  type:
|>    int, unsigned int, long, or unsigned long.

Correct.  I had just assumed that all conversions from enum to an
integral type were "conversions", and not "promotions".  Given that one
(and only one) of the conversions is a promotion, and that the rules in
13.3.3.1.1 favor promotions over conversions, the compiler should choose
the promotion.

I still wouldn't be too hard on Microsoft for this error, however.  The
distinction is subtle, and there has been some evolution in the draft
concerning the exact rules; maybe they are just following some earlier
version of the draft.  (I'm just guessing.  I don't know if there
actually was a version of the draft where this would have been
ambiguous.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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                             ]

Alex Bache wrote:
 >
 > Hi all,
 >
 > I have a question about the following code I wrote recently:
 >
 > class something
 > {
 >    public:
 >       enum e_error_code;
 >
 >    private:
 >       e_error_code errors;
 >
 >    public:
 >       enum e_error_code
 >       {
 >          okay,
 >          error
 >       };
 > };
 >
 > Under Microsoft Visual C++ V4.0 it compiles without any errors or
 > warnings, but under g++ (gcc 2.7.2) is issues an error about incomplete
 > enum definitions, or some such thing.
 >
 > So my question is this:  Which one is right?  Are enum prototypes
 > allowed, like class prototypes such as these:
 >
 > class A;
 >
 > class B
 > {
 >    A *ptr;
 > };
 >
 > class A
 > {
 >    int var;
 > };
 >
 > (I suppose there would be an error if I made the "A *ptr" part just "A
 > myA" ?)
 >
 > I would think that you could support partial enum definitions, because
 > you already know how large any enum is.  What's the thinking on this
 > one?

No you don't. The standard says that an enum must have enough bits to
represent the range of values. It's common for compilers to make enums
different numbers of bytes depending upon the range of their
enumerators. A compiler that makes all enums the same size might allow
this as an extension, but it's nonstandard.

--

Ciao,
Paul

(Please remove the "strip_these_words." prefix from the return
address, which has been altered to foil junk mail senders.)
---
[ 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                             ]

In article <3383FBAD.6988A2EC@sil.com>, Alex Bache  <bache@sil.com> wrote:
 >Hi all,
 >
 >I have a question about the following code I wrote recently:
 >
 >class something
 >{
 >   public:
 >      enum e_error_code;
 >
 >   private:
 >      e_error_code errors;
 >
 >   public:
 >      enum e_error_code
 >      {
 >         okay,
 >         error
 >      };
 >};
 >
 >
 >Under Microsoft Visual C++ V4.0 it compiles without any errors or
 >warnings, but under g++ (gcc 2.7.2) is issues an error about incomplete
 >enum definitions, or some such thing.
 >
 >So my question is this:  Which one is right?
 >Are enum prototypes
 >allowed, like class prototypes such as these:

gcc is right.. enums cannot be forward declared..

 >I would think that you could support partial enum definitions, because
 >you already know how large any enum is.  What's the thinking on this
 >one?

no there's the problem .. The size of the enum is not known till after
the end of the enum definition..

Alex Bache wrote:
>
> class something
> {
>    public:
>       enum e_error_code;
>    ...
>    public:
>       enum e_error_code
>       {
>          okay,
>          error
>       };
> };
>
> Under Microsoft Visual C++ V4.0 it compiles without any errors or
> warnings, but under g++ (gcc 2.7.2) is issues an error about incomplete
> enum definitions, or some such thing.

There is no such thing as an "enum prototype" or "enum forward
declaration" in C or C++. You cannot declare an enum without
providing its values. (C++ draft 7.2 "Enumeration declarations",
ISO C standard 6.5.2.2 "Enumeration specifiers" and 6.2.5.3 "Tags".)

Code like
 enum e ;
violates the syntax for enum declarations. A compiler might allow
the code as a nonportable extension, but must diagnose the error
in standard-conforming mode.

--
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                             ]

Hi all,

I have a question about the following code I wrote recently:

class something
{
   public:
      enum e_error_code;

   private:
      e_error_code errors;

   public:
      enum e_error_code
      {
         okay,
         error
      };
};


Under Microsoft Visual C++ V4.0 it compiles without any errors or
warnings, but under g++ (gcc 2.7.2) is issues an error about incomplete
enum definitions, or some such thing.

So my question is this:  Which one is right?  Are enum prototypes
allowed, like class prototypes such as these:

class A;

class B
{
   A *ptr;
};

class A
{
   int var;
};


(I suppose there would be an error if I made the "A *ptr" part just "A
myA" ?)

I would think that you could support partial enum definitions, because
you already know how large any enum is.  What's the thinking on this
one?

Alex.
---
[ 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
]