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,TURNIP=0x02,PARSNIP=0x04,SPROUT=0x08 } 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,TURNIP=0x02,PARSNIP=0x04,SPROUT=0x08 } 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,TURNIP=0x02,PARSNIP=0x04,SPROUT=0x08 } 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,TURNIP=0x02,PARSNIP=0x04,SPROUT=0x08 } 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 GardenVegetables {
CARROT=0x01,TURNIP=0x02,PARSNIP=0x04,SPROUT=0x08 };

GardenVegetables operator|(GardenVegetables veg1, GardenVegetables
veg2) {
return (GardenVegetables) ((int)veg1 | (int)veg2);
}

return static_cast<GardenVegetables>( ( 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.40348

Thierry Miceli posted:

enum GardenVegetables {
CARROT=0x01,TURNIP=0x02,PARSNIP=0x04,SPROUT=0x08 };

GardenVegetables operator|(GardenVegetables veg1, GardenVegetables
veg2) {
return (GardenVegetables) ((int)veg1 | (int)veg2);
}

return static_cast<GardenVegetables>( ( 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
GardenVegetables::GardenVegetables(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_cast).

Also, instead of

return (GardenVegetables) ((int)veg1 | (int)veg2);

one could say

return GardenVegetables ( (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_cast" 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_cast<int* const>(&p);
I myself never use (int). Here's how I do it:

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

Step 2) Use "reinterpret_cast".
I've never had to use "dynamic_cast" so far!
-JKop
-JKop

[Thierry Miceli]

> > GardenVegetables operator|(GardenVegetables veg1, GardenVegetables

veg2) {
return (GardenVegetables) ((int)veg1 | (int)veg2);
}

return static_cast<GardenVegetables>( ( 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.40397

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_cast" 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_cast. 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_cast<int* const>(&p);
I myself never use (int). Here's how I do it:

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

Step 2) Use "reinterpret_cast".
Agreed for pointer types only.
I've never had to use "dynamic_cast" 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_cast. 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