In article <3mmhh7$oco@kahu.mrtc.maui.com>, Paul Billings <pab@maui.com> wrote:

> mtm4@rsvl.unisys.com (Mike McCormick) wrote:
> >
> > On both my C++ compilers (Borland & cfront) it looks like the "enum"
data type
> > still has all the same deficiencies that make it practically worthless
IMHO in
> > C.  That is, there is still no compiler time error checking to ensure that
> > values assigned to the enum variable are in its set, nor does the compiler
> > allow a value to appear in more than one set.
>
> I beg to differ on the first point (BC4.5):
>
> enum Enum { A, B, C };
> enum Enum2 { D, E, F };
> void f()
> {
>         Enum e = A;
>         e = D;          // Warning: Assigning Enum2 to Enum in function f()
>         e = 10;         // Warning: Assigning int to Enum in function f()
> }

What? Several people have posted here that BC 4.5 sucks, doesn't work,
don't buy it, etc. This must be a bug in the Borland compiler.

--
Gregory Jorgensen
radix consulting inc
radixinc@aol.com, radix@efn.org

"I would consent to have a limb amputated to recover my spirits." -- Samuel Johnson

radix@efn.org (Gregory Jorgensen) writes:

>In article <3mmhh7$oco@kahu.mrtc.maui.com>, Paul Billings <pab@maui.com> wrote:

>> mtm4@rsvl.unisys.com (Mike McCormick) wrote:
>> >
>> > On both my C++ compilers (Borland & cfront) it looks like the "enum"
>data type
>> > still has all the same deficiencies that make it practically worthless
>IMHO in
>> > C.  That is, there is still no compiler time error checking to ensure that
>> > values assigned to the enum variable are in its set, nor does the compiler
>> > allow a value to appear in more than one set.
>>
>> I beg to differ on the first point (BC4.5):
>>
>> enum Enum { A, B, C };
>> enum Enum2 { D, E, F };
>> void f()
>> {
>>         Enum e = A;
>>         e = D;          // Warning: Assigning Enum2 to Enum in function f()
>>         e = 10;         // Warning: Assigning int to Enum in function f()
>> }

>What? Several people have posted here that BC 4.5 sucks, doesn't work,
>don't buy it, etc. This must be a bug in the Borland compiler.

Unlikely, Borland C++'s language support is top-notch.  In a recent PC
Magazine review of C++ compilers, Borland C++ 4.5 rated 8.0 (on a scale of
10---10 representing "perfect" C++ support as documented in the current
draft standard) while Microsoft Dismal (uh, a mean "Visual") C++ 1.51 scored
2.6 using the "Plum-Hall Validation Suite for C++".  Even VC++ 2.0 only
scored an underwhelming 5.3 out of 10.  Borland was tied with MetaWare's
High C/C++ 3.3 in the same review.  In the specific Plum-Hall catagory of
"General coverage of C++ features", Borland C++ scored a 10.

Also, having used Borland C++ since it first appeared, I am not surprised
the C++ enums are better supported than with your average compiler.  In
short, if you are not programming with Borland or MetaWare, you're probaby
making do with inferior C++ support.  In the Windows/DOS world, Borland C++
4.5 is as close as you can get to state-of-the-art C++ langauge support.

Also, I'd take the opinions *some* people post here with a grain of salt.
Anyone willing to post the world that something "sucks" in ALL CAPS (as
has been done about BC++ 4.5) probably doesn't really know what they're
talking about, probably doesn't really "get" C++ or is otherwise in any sort
of position to judge C++ compilers.  In my view, Borland is one of the best
vendors in their market, specifically because of their excellent language
support.

-------------------------------------------------------------------------
Matt Arnold                       |        | ||| | |||| |  | | || ||
marnold@netcom.com                |        | ||| | |||| |  | | || ||
Boston, MA                        |      0 | ||| | |||| |  | | || ||
617.389.7384 (h) 617.576.2760 (w) |        | ||| | |||| |  | | || ||
Windows C++ developer             |        | ||| 4 3 1   0 8 3 || ||
-------------------------------------------------------------------------

vawjr08@ibm.net wrote:
> In <marnoldD7GIyA.1rv@netcom.com>, marnold@netcom.com (Matt Arnold) writes:
> >Unlikely, Borland C++'s language support is top-notch.

> Yeah, right!  Well, maybe it's improved since the evening we called to report
> that they didn't always pay attention to the 'volatile' keyword.  It only took us
> aobut 12 man hours to find the problem and their ENTIRE interest was:
> "Well, it says it's a _HINT_ in the manual"

> Well, we quit using them right then.  They didn't want a report unless we could
> get it down to less than 100 lines of code.  Too f***ing bad.  NO customer
> of ours since has used Borland.

IMHO, if you couldn't get it down to less than 100 lines of code, it
probably _was_ your code.  WTHW, you oughta check out the code that
alters the volatile variable.  Bet you find some suprises ;-), ahh, but
it's so much easer to bash the tools..., ain't it?
--

In article <radix-1304950028140001@net15.efn.org>, radix@efn.org (Gregory Jorgensen) writes:
[..]
|>
|> Yes I think this was discussed and rejected.
|>

It would be nice to see a (complete) list of such topics.


Ulf Schuenemann

--------------------------------------------------------------------
Ulf Sch   nemann
Fakult   t f   r Informatik, Technische Universit   t M   nchen, Germany.
email: schuenem@informatik.tu-muenchen.de

In <3n0u0e$850@hpsystem1.informatik.tu-muenchen.de>
schuenem@Informatik.TU-Muenchen.DE (Ulf Schuenemann) writes:
>
>
>In article <radix-1304950028140001@net15.efn.org>, radix@efn.org
(Gregory Jorgensen) writes:
>[..]
>|>
>|> Yes I think this was discussed and rejected.
>|>
>
>It would be nice to see a (complete) list of such topics.
>
>
>Ulf Schuenemann
>
>--------------------------------------------------------------------
>Ulf Sch   nemann
>Fakult   t f   r Informatik, Technische Universit   t M   nchen, Germany.
>email: schuenem@informatik.tu-muenchen.de

Actually, "The Design And Evolution of C++" by Bjarne Stroustrup
contains a whole bunch of C++ extension proposals that were discussed
and ultimately rejected. It's interesting reading (if you're into C++),
anyway !

Regards,
Timo.

----------------------------------------------------------------------
Timo S. Kissel, Dipl. Inf. (FH)                 tskissel@ix.netcom.com

In article <radix-1304950028140001@net15.efn.org>,
Gregory Jorgensen <radix@efn.org> wrote:
>In article <mtm4.717.00C1C0EC@rsvl.unisys.com>, mtm4@rsvl.unisys.com (Mike
>McCormick) wrote:
>
>> On both my C++ compilers (Borland & cfront) it looks like the "enum"
>data type
>> still has all the same deficiencies that make it practically worthless
>IMHO in
>> C.  That is, there is still no compiler time error checking to ensure that
>> values assigned to the enum variable are in its set, nor does the compiler
>> allow a value to appear in more than one set.
>>
>> Am I right about this on both counts?
>
>I don't think enum is worthless, but you are right that it doesn't work
>the way you think it should.

 What? Borland for sure implements the new semantics
adopted by the C++ committee. An enumeration declaration
defines a type distinct from other types. You cannot assign,
copy, pass, or otherwise initialise a variable of an enumeration
type E with a value of any type other than E.

 Checking is done AT COMPILE TIME, conforming
compilers must issue a diagnostic error message if you break the rule.

 An enum E has an implicit conversion to each
integral type (as safe as integral conversions and no safer).

 An integral type can be converted to an enumeration type
with an _explicit_ cast.  No error is possible. If the integral
value is outside the range of the enumeration, an unspecified
value is selected.

 Your second point is correct. Enums are not
well designed. So _use_ them like this:

 struct X { enum E {value1, ... } };

so that the values are "encapsulated" in the class X.
The failure to nest enumeration constants in the
enumeration is historical and cannot be corrected
without breaking reams of C and C++ code.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

Gregory Jorgensen (radix@efn.org) wrote:
: In article <mtm4.717.00C1C0EC@rsvl.unisys.com>, mtm4@rsvl.unisys.com (Mike
: McCormick) wrote:

: > On both my C++ compilers (Borland & cfront) it looks like the "enum"
: data type
: > still has all the same deficiencies that make it practically worthless
: IMHO in
: > C.  That is, there is still no compiler time error checking to ensure that
: > values assigned to the enum variable are in its set, nor does the compiler
: > allow a value to appear in more than one set.
: >
: > Am I right about this on both counts?

: I don't think enum is worthless, but you are right that it doesn't work
: the way you think it should.

: >
: > If so, will the ANSI/ISO standard do anything to beef up "enum" in C++?  That
: > would seem to be right in line with the philosophy of stronger type checking
: > in C++ being more important than compatibility with C.
: >
: > If not, did the Committee (or Stroustrup or anyone else) ever consider doing
: > this?...

: Yes I think this was discussed and rejected.

I'm confused about your problem.  An enum variable can only be assigned
values in it's set.  There are no implicit conversions of int to
an enum type in C++ (although there are in C).  Isn't this what your
complaining about?  They are not "worthless".  I use them often.

-- Joshua Allen

In article <mtm4.717.00C1C0EC@rsvl.unisys.com>, mtm4@rsvl.unisys.com (Mike
McCormick) wrote:

> On both my C++ compilers (Borland & cfront) it looks like the "enum"
data type
> still has all the same deficiencies that make it practically worthless
IMHO in
> C.  That is, there is still no compiler time error checking to ensure that
> values assigned to the enum variable are in its set, nor does the compiler
> allow a value to appear in more than one set.
>
> Am I right about this on both counts?

I don't think enum is worthless, but you are right that it doesn't work
the way you think it should.

>
> If so, will the ANSI/ISO standard do anything to beef up "enum" in C++?  That
> would seem to be right in line with the philosophy of stronger type checking
> in C++ being more important than compatibility with C.
>
> If not, did the Committee (or Stroustrup or anyone else) ever consider doing
> this?...

Yes I think this was discussed and rejected.

--
Gregory Jorgensen
radix consulting inc
radixinc@aol.com, radix@efn.org

"I would consent to have a limb amputated to recover my spirits." -- Samuel Johnson

mtm4@rsvl.unisys.com (Mike McCormick) wrote:
>
> On both my C++ compilers (Borland & cfront) it looks like the "enum" data type
> still has all the same deficiencies that make it practically worthless IMHO in
> C.  That is, there is still no compiler time error checking to ensure that
> values assigned to the enum variable are in its set, nor does the compiler
> allow a value to appear in more than one set.

I beg to differ on the first point (BC4.5):

enum Enum { A, B, C };
enum Enum2 { D, E, F };
void f()
{
 Enum e = A;
 e = D;  // Warning: Assigning Enum2 to Enum in function f()
 e = 10;  // Warning: Assigning int to Enum in function f()
}

Concerning a value appearing in more than one set: usually the entries
are separate "things" and shouldn't be in more than one set.  However, in
other cases they should be and there is a clean way to do it.

Class Shape {
   enum Color { black, red, white, blue } color;
};
class Car {
   enum Color { red, white, pea_green } color;
};

Use Shape::red or Car::red depending on purpose.  Note it would be nonsense
to try to do if(car.color == Shape::red).  They are similiar--but separate--
concepts.

Paul

mtm4@rsvl.unisys.com (Mike McCormick) writes:

>On both my C++ compilers (Borland & cfront) it looks like the "enum" data type
>still has all the same deficiencies that make it practically worthless IMHO in
>C.  That is, there is still no compiler time error checking to ensure that
>values assigned to the enum variable are in its set,

The situation is "worse" in C++ than in C. The new C++ rule is that any
value which can be represented in the number of bits required to
represent all the defined enum values is explicitly valid. Example:
 enum E { lo=0, hi=10 };
 E e = (E)5; // valid in C++, but not in C

>nor does the compiler allow a value to appear in more than one set.

Values can be repeated as often as you like. Identifiers must be
unique in their scope. Thus:
 enum E1 { a=1, b=2, c=1, d=2 }; // repeated values in one enum OK
 enum E2 { e=1, f=2, g=1, h=2 }; // repeated values yet again OK
 class T { // new scope
     enum E3 { a=1, b=2 }; // repeated id's OK in new scope
 };
This rule comes out of the scoping rules of identifiers, and is the
same in Pascal, for example.

>If so, will the ANSI/ISO standard do anything to beef up "enum" in C++?

No further changes in enums are contemplated.

>If not, did the Committee (or Stroustrup or anyone else) ever consider doing
>this?...

Several of proposals have been presented on the subject of enums.
Some have been accepted (e.g., extra values, overloading operators on enum),
and some have been rejected (e.g., forward declaration of enum).

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

On both my C++ compilers (Borland & cfront) it looks like the "enum" data type
still has all the same deficiencies that make it practically worthless IMHO in
C.  That is, there is still no compiler time error checking to ensure that
values assigned to the enum variable are in its set, nor does the compiler
allow a value to appear in more than one set.

Am I right about this on both counts?

If so, will the ANSI/ISO standard do anything to beef up "enum" in C++?  That
would seem to be right in line with the philosophy of stronger type checking
in C++ being more important than compatibility with C.

If not, did the Committee (or Stroustrup or anyone else) ever consider doing
this?...

------------------------------------------------------------------
 Mike McCormick
 mtm4@rsvl.unisys.com
 m.mccormick2@genie.geis.com
------------------------------------------------------------------
 While you're out surfing the internet...
 I'm back on the beach blowing my little lifeguard whistle.
------------------------------------------------------------------