enums in C and C++

[Simon Elliott]

I'm porting thousands of lines of legacy C code to C++. One makor issue
I've got is that of enums being treated differently in C and C++.
There's an automatic cast from int to enum in C but not in C++. The
code is full of constructs like this:

enum { CARROT=0x01,TUR NIP=0x02,PARSNI P=0x04,SPROUT=0 x08 } garden_veg;

garden_veg = CARROT|PARSNIP; /* Fine in C, but not in C++ */

Do I really have to trawl through all this code and put in many
hundreds of casts, or is there something clever I can do to get round
this?

--
Simon Elliott http://www.ctsn.co.uk

[Victor Bazarov]

Simon Elliott wrote:

I'm porting thousands of lines of legacy C code to C++. One makor issue
I've got is that of enums being treated differently in C and C++.
There's an automatic cast from int to enum in C but not in C++. The
code is full of constructs like this:

enum { CARROT=0x01,TUR NIP=0x02,PARSNI P=0x04,SPROUT=0 x08 } garden_veg;

garden_veg = CARROT|PARSNIP; /* Fine in C, but not in C++ */

Do I really have to trawl through all this code and put in many
hundreds of casts, or is there something clever I can do to get round
this?

The only "clever" thing to do is to keep this C (if it worked before, why
change?)

V

[Artie Gold]

Simon Elliott wrote:

I'm porting thousands of lines of legacy C code to C++. One makor issue
I've got is that of enums being treated differently in C and C++.
There's an automatic cast from int to enum in C but not in C++. The
code is full of constructs like this:

enum { CARROT=0x01,TUR NIP=0x02,PARSNI P=0x04,SPROUT=0 x08 } garden_veg;

garden_veg = CARROT|PARSNIP; /* Fine in C, but not in C++ */

Do I really have to trawl through all this code and put in many
hundreds of casts, or is there something clever I can do to get round
this?

Why are you bothering to port C code to C++?* Leave it in C and call
what you need (from C++).

HTH,
--ag

* - No slam on C++ intended; just a practical comment.

--
Artie Gold -- Austin, Texas

"If you don't think it matters, you're not paying attention."

[JKop]

Thierry Miceli posted:

enum { CARROT=0x01,TUR NIP=0x02,PARSNI P=0x04,SPROUT=0 x08 } garden_veg;

garden_veg = CARROT|PARSNIP; /* Fine in C, but not in C++ */

Do I really have to trawl through all this code and put in many
hundreds of casts, or is there something clever I can do to get round
this?
If you really want to convert the code to C++ you could try to

redefine the '|' operator for the enum. e.g:

enum GardenVegetable s {
CARROT=0x01,TUR NIP=0x02,PARSNI P=0x04,SPROUT=0 x08 };

GardenVegetable s operator|(Garde nVegetables veg1, GardenVegetable s
veg2) {
return (GardenVegetabl es) ((int)veg1 | (int)veg2);
}

return static_cast<Gar denVegetables>( ( static_cast<int >(veg1) |
static_cast<int >(veg2) ) );
C++, not C/C++ ;-D
-JKop

[Siemel Naran]

"JKop" <NU**@NULL.NULL > wrote in message news:Pyngd.4034 8

Thierry Miceli posted:

enum GardenVegetable s {
CARROT=0x01,TUR NIP=0x02,PARSNI P=0x04,SPROUT=0 x08 };

GardenVegetable s operator|(Garde nVegetables veg1, GardenVegetable s
veg2) {
return (GardenVegetabl es) ((int)veg1 | (int)veg2);
}

return static_cast<Gar denVegetables>( ( static_cast<int >(veg1) |
static_cast<int >(veg2) ) );
C++, not C/C++ ;-D

It seems fine to use C style casts for converting one integer/float type to
another. Imagine that there exists a constructor
GardenVegetable s::GardenVegeta bles(int). Only for converting one
pointer/reference type to another do I use one of the C++ style casts
(usually static_cast, but sometimes reinterpret_cas t).

Also, instead of

return (GardenVegetabl es) ((int)veg1 | (int)veg2);

one could say

return GardenVegetable s ( (int(veg1) | int(veg2)) );

but neither way is superior, though I'm not sure if this second way is
allowed in C.
Similarly, "(size_t)i" which is equivalent to "size_t(i)" where i is an int,
also seems fine to me as a good style of C++.

[JKop]

Similarly, "(size_t)i" which is equivalent to "size_t(i)" where i is an int, also seems fine to me as a good style of C++.

See but that's why "reinterpret_ca st" was given such a horrid name:
float p;

int* k = (int*) &p; //legal

int* k = int*(&p) ; // no can do
To achieve this, you need to be horrid:

int* k = reinterpret_cas t<int* const>(&p);
I myself never use (int). Here's how I do it:

Step 1) Use "static_cas t". If rejected go to step 2.

Step 2) Use "reinterpret_ca st".
I've never had to use "dynamic_ca st" so far!
-JKop
-JKop

[Thierry Miceli]

> > GardenVegetable s operator|(Garde nVegetables veg1, GardenVegetable s

veg2) {
return (GardenVegetabl es) ((int)veg1 | (int)veg2);
}

return static_cast<Gar denVegetables>( ( static_cast<int >(veg1) |
static_cast<int >(veg2) ) );
C++, not C/C++ ;-D

I agree, I sacrificed purity for readability.

Thierry

[Siemel Naran]

"JKop" <NU**@NULL.NULL > wrote in message news:M7pgd.4039 7

Similarly, "(size_t)i" which is equivalent to "size_t(i)" where i is an

int, also seems fine to me as a good style of C++.

See but that's why "reinterpret_ca st" was given such a horrid name:
float p;

int* k = (int*) &p; //legal

int* k = int*(&p) ; // no can do

I agree that for casting between pointer and reference types, it's good to
use static_cast or reinterpret_cas t. But for casting between value types, C
style casts which behave like constructors, seem perfectly fine.

To achieve this, you need to be horrid:

int* k = reinterpret_cas t<int* const>(&p);
I myself never use (int). Here's how I do it:

Step 1) Use "static_cas t". If rejected go to step 2.

Step 2) Use "reinterpret_ca st".
Agreed for pointer types only.
I've never had to use "dynamic_ca st" so far!

It arises when writing generic code, and you can't or don't want to edit the
base class by continually adding virtual functions to it.

[Ioannis Vranos]

Siemel Naran wrote:

I agree that for casting between pointer and reference types, it's good to
use static_cast or reinterpret_cas t. But for casting between value types, C
style casts which behave like constructors, seem perfectly fine.

C++ newer casts are still better.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Simon Elliott]

On 28/10/2004, Simon Elliott wrote:
[snip]

Thanks for all the responses to this. I'm still unsure about how to
proceed because there are lots of different enums which are used in
lots of different ways. With the current compiler (BCB3) I have the
(slightly grubby) option of suppressing the warning and leaving
everything as it is. But it's possible that other compilers won't let
me do this.

--
Simon Elliott http://www.ctsn.co.uk