enum problem

[eeisemann]

Hi,
unfortunately I have a huge problem with enum types.
I declared the following type:
enum myType {DIFFERENCE,B,C,D};

I introduced a data structure containing this type and including the header for the enum type:
class DATA
{
...
myType test;
...
}

In one part of my program (which is quite large) there is a conditional:

if (_data->test==DIFFERENCE)

where _data is a pointer on a DATA class.

This test always fails. Even if the debugger tells me that _data->test has the value DIFFERENCE.
If I test the value of _data->test==DIFFERENCE in the debugger window, it is equal to 1, as it should be.
Tests for B, C, D work the way they should.
(I already tried to use enum myType {DIFFERENCE=1,B=2,C=3,D=4}; but the error did not disappear)

The most astonishing fact is, that the same error occurs when I run the Microsoft Compiler.
So it may be that it is a Visual Studio bug...

Has anybody an idea what I could have done wrong?
Is there anything one should be aware of, when using enum types?

Thank you very much for your help.

[cp_jain]

Hi
I compiled a similar program on linux with Intel compiler v7.1 and it worked.

Here is the sample code -

#include

enum myType {DIFFERENCE,B,C,D};

class DATA
{
public:
myType test;
};


int main()
{
DATA *d1 = new DATA;
d1->test = DIFFERENCE;

if (d1->test==DIFFERENCE) {
printf("Ok ");
}
return 0;
}

$ icpc test.cpp
$ ./a.out
Ok
$

CP

[davids]

Most likely the bug is in your code, and there's no way anyone could help you find it just from what you've posted. It may help to try to find the smallest possible complete piece of code that replicates the problem. It could be something as simple as a syntax issue (extra semicolon, for example).

It may help to have someone else look at the code. Sometimes we manage to keep avoiding looking at the one place we really need to look because we kind of get stuck. A fresh eye can make all the difference.

DS

[eeisemann]

Thank you for your help.

Finally I found out where the error is coming from.

The simplest program to provoke the error is the following:


//MyHeader.h
enum myType {DIFFERENCE=3,B=4,C=5,D=6};

class DATA
{
public:
static myType test;
};

myType DATA::test=DIFFERENCE;



//main.cpp
#include "myHeader.h"
#include
#include

int main()
{
DATA *d1 = new DATA;

int i=1;
if (d1->test==DIFFERENCE) {
i=2;
}
return i;
}

The program returns 1!


It seems as if windows.h defined DIFFERENCE, but the compiler does not show a warning when comparing the enum type with this windows.h defined type.
It is interesting, that trying to assign DIFFERENCE to d1->test leads to an error due to illegal type conversion. (So in my opinion it should also be an error (or at least a warning) to compare an enum type to int, because as far as I know, although enums are INTs, the final value of enum constants is not known in general before compiling the program. And they have been introduced to avoid this kind of trouble)

Anyway the moral seems to be, that one should not develop under windows...

Thank you again.
And sorry for not giving the information about the windows.h, but I really did not expect this to be the source of the problem.

[mwatt]

It's defined in winuser.h:

#define DIFFERENCE 11

It's really nasty of MS to use a name like that. And if you look at the way it is used in winuser.h, it looks completely unnecessary as well.

Now in terms of having the compiler catch it, I don't think you can ask it to complain if you compare an enum to an int - that is such a common workflow. However what would be useful is to warn if the user does a #define using a name that is already being used. No other compiler I tried gave a warning for this case either, but gcc has a really nice flag "-Wshadow" which warns if you are using the same variable name twice in the same scope. Maybe Intel could add a warning like this, and incorporate checking for a #define shadowing a previously declared variable as well?

[serge-pashkov]

But compiler can not distinguish this case because of DIFFERENCE is processed by preprocessor.
So compiler is seeing only line
d->type == 11

But this is style issue. It is rule of thumb that UPPERCASE used for preprocessing so using this kind of own types or identificators is prune to various unexpected errors.