473,320 Members | 1,920 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

enum members namespace clash

Hi,

I have two different enum definitions with members of same name. The
compiler complains about duplicate definitions. Is this expected
behaviour?

Can't I have same-named fields in different enum definitions? I think
it should have been perfectly valid to do that. Its a stupid limitation
to have to define disjoint enum symbol definitions. This is like having
to have disjoint member names in structures.

Bahadir

Nov 14 '05 #1
21 6299
On 2 Jun 2005 09:12:04 -0700, Bi*************@gmail.com wrote:
Hi,

I have two different enum definitions with members of same name. The
compiler complains about duplicate definitions. Is this expected
behaviour?


Yes, enumeration constants are in one and the same namespace (which
they share with functions, variables and typedef names).

See 1.29 from the FAQ.
Nov 14 '05 #2
Bi*************@gmail.com wrote:

Hi,

I have two different enum definitions with members of same name. The
compiler complains about duplicate definitions. Is this expected
behaviour?

Can't I have same-named fields in different enum definitions? I think
it should have been perfectly valid to do that.
Its a stupid limitation
to have to define disjoint enum symbol definitions.
This is like having
to have disjoint member names in structures.


Not really. You have no way of knowing which enum
a member belongs to, if members have the same name.

enum forward {ZERO, ONE};
enum backward{ONE, ZERO};

return ZERO;

Perhaps,
if your enum members have the same name at the same value,
you could do better with only one enum?

--
pete
Nov 14 '05 #3
Bi*************@gmail.com writes:
I have two different enum definitions with members of same name. The
compiler complains about duplicate definitions. Is this expected
behaviour?
Yes.
Can't I have same-named fields in different enum definitions?
No.
I think it should have been perfectly valid to do that. Its a
stupid limitation to have to define disjoint enum symbol
definitions. This is like having to have disjoint member names
in structures.


You could always switch to C++. It has features that can do what
you want. Short of that, the standard practice is to use a
unique prefix for each enumerated type.
--
Ben Pfaff
email: bl*@cs.stanford.edu
web: http://benpfaff.org
Nov 14 '05 #4
Bi*************@gmail.com wrote:
Hi,

I have two different enum definitions with members of same name. The
compiler complains about duplicate definitions. Is this expected
behaviour?

Can't I have same-named fields in different enum definitions? I think
it should have been perfectly valid to do that. Its a stupid limitation
to have to define disjoint enum symbol definitions. This is like having
to have disjoint member names in structures.

Bahadir


Enumeration constants in C are of type `int' and enumeration constant
identifiers are unqualified when used. If the same identifier occurs in
different enumerations there is no way for the compiler to know which
one to use.
-- August
Nov 14 '05 #5
August Karlstrom wrote:
Bi*************@gmail.com wrote:
Hi,

I have two different enum definitions with members of same name. The
compiler complains about duplicate definitions. Is this expected
behaviour?

Can't I have same-named fields in different enum definitions? I think
it should have been perfectly valid to do that. Its a stupid limitation
to have to define disjoint enum symbol definitions. This is like having
to have disjoint member names in structures.

Bahadir


Enumeration constants in C are of type `int' and enumeration constant
identifiers are unqualified when used. If the same identifier occurs in
different enumerations there is no way for the compiler to know which
one to use.


Which brings us to the question why enumerations in C aren't qualified.
Probably because that way things would get rather verbose:

f(SomeEnum.A_CONSTANT | SomeEnum.ANOTHER_CONSTANT
| SomeEnum.A_THIRD_CONSTANT);

rather than

f(A_CONSTANT | ANOTHER_CONSTANT | A_THIRD_CONSTANT);
-- August
Nov 14 '05 #6
Bi*************@gmail.com wrote:
Hi,

I have two different enum definitions with members of same name. The
compiler complains about duplicate definitions. Is this expected
behaviour?

Can't I have same-named fields in different enum definitions? I think
it should have been perfectly valid to do that. Its a stupid limitation
to have to define disjoint enum symbol definitions. This is like having
to have disjoint member names in structures.


Another strategy is to forget the `enum' feature and use plain integer
constants (I use double quotes for these pseudo enumerations from now
on). As long as all "enumeration" constants have distinct values, there
is no problem with sharing a constant between different "enumerations".
This is also a safer approach since if a client uses an "enumeration"
constant from the wrong "enumeration" it will be detected.
-- August
Nov 14 '05 #7
August Karlstrom <fu********@comhem.se> writes:
[...]
Which brings us to the question why enumerations in C aren't
qualified. Probably because that way things would get rather verbose:

f(SomeEnum.A_CONSTANT | SomeEnum.ANOTHER_CONSTANT
| SomeEnum.A_THIRD_CONSTANT);

rather than

f(A_CONSTANT | ANOTHER_CONSTANT | A_THIRD_CONSTANT);


The language *could* have been defined so that an enumeration constant
can be used without qualification if there's no ambiguity, with some
kind of qualification syntax to be used if there's another constant of
the same name. There are languages that do this. C, unsurprisingly,
isn't one of them.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #8
Keith Thompson wrote:
August Karlstrom <fu********@comhem.se> writes:
[...]
Which brings us to the question why enumerations in C aren't
qualified. Probably because that way things would get rather verbose:

f(SomeEnum.A_CONSTANT | SomeEnum.ANOTHER_CONSTANT
| SomeEnum.A_THIRD_CONSTANT);

rather than

f(A_CONSTANT | ANOTHER_CONSTANT | A_THIRD_CONSTANT);

The language *could* have been defined so that an enumeration constant
can be used without qualification if there's no ambiguity, with some
kind of qualification syntax to be used if there's another constant of
the same name. There are languages that do this. C, unsurprisingly,
isn't one of them.


What language do you have in mind?

Nov 14 '05 #9
August Karlstrom <fu********@comhem.se> writes:
Keith Thompson wrote:
August Karlstrom <fu********@comhem.se> writes:
[...]
Which brings us to the question why enumerations in C aren't
qualified. Probably because that way things would get rather verbose:

f(SomeEnum.A_CONSTANT | SomeEnum.ANOTHER_CONSTANT
| SomeEnum.A_THIRD_CONSTANT);

rather than

f(A_CONSTANT | ANOTHER_CONSTANT | A_THIRD_CONSTANT);

The language *could* have been defined so that an enumeration
constant
can be used without qualification if there's no ambiguity, with some
kind of qualification syntax to be used if there's another constant of
the same name. There are languages that do this. C, unsurprisingly,
isn't one of them.


What language do you have in mind?


<OT>
Ada.

Given a type declaration
type Enum is (Zero, One, Two);
each constant is equivalent to a function with no parameters returning
Enum. (Ada doesn't use empty parentheses for parameterless function
calls.) Enumeration constants aren't really implemented as functions,
and they can be used in constant expressions, but it allows all the
overloading rules that apply to functions to apply to enumeration
constants.
</OT>

Using the same approach in C would violate the "Spirit of C", I think.
Using another approach that's specific to enum types (and inventing a
syntax for the qualification) probably wouldn't be worth the effort.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #10

In article <F5*******************@newsb.telia.net>, August Karlstrom <fu********@comhem.se> writes:
Keith Thompson wrote:

The language *could* have been defined so that an enumeration constant
can be used without qualification if there's no ambiguity, with some
kind of qualification syntax to be used if there's another constant of
the same name. There are languages that do this. C, unsurprisingly,
isn't one of them.


What language do you have in mind?


COBOL does this for its equivalent of structure members and the like.
(Whether it does it for all "enumeration constants" is a bit less
clear. I'm pretty sure level-88s are scoped and support both implicit
and explicit qualification. I don't think level-78s do, but those
are a Micro Focus extension, not part of the standard language.)

So in COBOL you only need the item name if it's unique; if not, you
have to qualify it.

ObC: I recently had quite a tussle with someone in comp.lang.cobol
over whether this difference between COBOL and C counted in favor of
the former or the latter - or rather whether C was flawed by its lack
of implicit qualification. I'm glad that C requires explicit
qualification; the small additional cost in writing code is more than
recovered when maintaining it, I think. Making the maintenance
programmer guess what variable is being referenced is not a good
move, in my book.

On the same note, I'm just as happy that C doesn't have Pascal's WITH
construct. While that would occasionally clean up some bits of code,
it can produce some rather hairy ambiguities, too.

Of course, C99 gives us compound literals with designations, which
provides some of the syntactic sugar of implicit qualification and
WITH, but in a more restricted and so perhaps somewhat cleaner way.

--
Michael Wojcik mi************@microfocus.com

Be sure to push the button of the bottom, and push the button of the
settlement page indicated next only once, there is fear of the bottom
rhinoceros multiplex lesson money. -- Sukebe Net
Nov 14 '05 #11
August Karlstrom wrote:
Bi*************@gmail.com wrote:
Hi,

I have two different enum definitions with members of same name. The
compiler complains about duplicate definitions. Is this expected
behaviour?

Can't I have same-named fields in different enum definitions? I think
it should have been perfectly valid to do that. Its a stupid limitation
to have to define disjoint enum symbol definitions. This is like having
to have disjoint member names in structures.

Others have commented on this already; usually, you work with prefixes
which make it harder to get enumeration constant names to clash.

Another strategy is to forget the `enum' feature and use plain integer
constants (I use double quotes for these pseudo enumerations from now
on). As long as all "enumeration" constants have distinct values, there
is no problem with sharing a constant between different "enumerations".
This is also a safer approach since if a client uses an "enumeration"
constant from the wrong "enumeration" it will be detected.


Usually, enum is a safe way to go because it does keep the values
distinct for you. Thus, if you have to insert another constant between
to certain constants, you do not have to adjust the values manually
and cannot make any mistakes there.
I do not see the advantages of your approach; maybe you can give a
little example... ?
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Nov 14 '05 #12
Michael Mair wrote:
August Karlstrom wrote:
Bi*************@gmail.com wrote:
Hi,

I have two different enum definitions with members of same name. The
compiler complains about duplicate definitions. Is this expected
behaviour?

Can't I have same-named fields in different enum definitions? I think
it should have been perfectly valid to do that. Its a stupid limitation
to have to define disjoint enum symbol definitions. This is like having
to have disjoint member names in structures.

Others have commented on this already; usually, you work with prefixes
which make it harder to get enumeration constant names to clash.

Another strategy is to forget the `enum' feature and use plain integer
constants (I use double quotes for these pseudo enumerations from now
on). As long as all "enumeration" constants have distinct values,
there is no problem with sharing a constant between different
"enumerations". This is also a safer approach since if a client uses
an "enumeration" constant from the wrong "enumeration" it will be
detected.

Usually, enum is a safe way to go because it does keep the values
distinct for you. Thus, if you have to insert another constant between
to certain constants, you do not have to adjust the values manually
and cannot make any mistakes there.
I do not see the advantages of your approach; maybe you can give a
little example... ?


$ cat test.c
#include <stdio.h>

enum e1 {C1};
enum e2 {C2};

void f(enum e1 e)
{
switch (e) {
case C1:
printf("Hi I'm function f, I think I'm dealing with e = C1\n");
break;
}
}
int main(void)
{
f(C2);
return 0;
}
$ ./test
Hi I'm function f, I think I'm dealing with e = C1
-- August
Nov 14 '05 #13
August Karlstrom wrote:
Michael Mair wrote:
August Karlstrom wrote:
Bi*************@gmail.com wrote:

Hi,

I have two different enum definitions with members of same name. The
compiler complains about duplicate definitions. Is this expected
behaviour?

Can't I have same-named fields in different enum definitions? I think
it should have been perfectly valid to do that. Its a stupid limitation
to have to define disjoint enum symbol definitions. This is like having
to have disjoint member names in structures.


Others have commented on this already; usually, you work with prefixes
which make it harder to get enumeration constant names to clash.

Another strategy is to forget the `enum' feature and use plain
integer constants (I use double quotes for these pseudo enumerations
from now on). As long as all "enumeration" constants have distinct
values, there is no problem with sharing a constant between different
"enumerations". This is also a safer approach since if a client uses
an "enumeration" constant from the wrong "enumeration" it will be
detected.


Usually, enum is a safe way to go because it does keep the values
distinct for you. Thus, if you have to insert another constant between
to certain constants, you do not have to adjust the values manually
and cannot make any mistakes there.
I do not see the advantages of your approach; maybe you can give a
little example... ?

$ cat test.c
#include <stdio.h>

enum e1 {C1};
enum e2 {C2};

void f(enum e1 e)
{
switch (e) {
case C1:
printf("Hi I'm function f, I think I'm dealing with e = C1\n");
break;
}
}
int main(void)
{
f(C2);
return 0;
}
$ ./test
Hi I'm function f, I think I'm dealing with e = C1


Thanks for the example -- now I have understood what you mean.

BTW: My build process includes
$ splint test.c
....
Function f expects arg 1 to be enum e1 gets enum e2 { C2 }: C2
Types are incompatible
....
and would have caught this one.

However, if one wants globally distinct integer values, I
would once more suggest an enumeration:

enum AllTheConstants {
E1_START,
E1_C1 = E1_START,
....
E1_SOMETHING,
E1_END = E1_SOMETHING,

E2_START,
E2_C2 = E2_START,
.....
};
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
Nov 14 '05 #14
Michael Mair wrote:
August Karlstrom wrote:
$ cat test.c
#include <stdio.h>

enum e1 {C1};
enum e2 {C2};

void f(enum e1 e)
{
switch (e) {
case C1:
printf("Hi I'm function f, I think I'm dealing with e = C1\n");
break;
}
}
int main(void)
{
f(C2);
return 0;
}
$ ./test
Hi I'm function f, I think I'm dealing with e = C1

Thanks for the example -- now I have understood what you mean.

BTW: My build process includes
$ splint test.c
....
Function f expects arg 1 to be enum e1 gets enum e2 { C2 }: C2
Types are incompatible
....
and would have caught this one.


Yes, you're right, I noticed that myself. A lint program is more or less
mandatory for serious development.
However, if one wants globally distinct integer values, I
would once more suggest an enumeration:

enum AllTheConstants {
E1_START,
E1_C1 = E1_START,
....
E1_SOMETHING,
E1_END = E1_SOMETHING,

E2_START,
E2_C2 = E2_START,
....
};


To sum it up:

Separate enums and lint checking: The best approach, the only drawback
being that different enums cannot share the same identifier. In that
case the constants have to be prefixed.

Macro constants with distinct values: Second best. No static type
checking possible (not even by lint) but wrong usage will at least lead
to a runtime exception (if the program has been carefully designed that
is). For clarity a type synonym can be introduced, e.g. `typedef int Color'.

Separate enums without lint checking: Worst. My example above
illustrates the problem.
-- August
Nov 14 '05 #15
August Karlstrom wrote:
Keith Thompson wrote:
The language *could* have been defined so that an enumeration constant
can be used without qualification if there's no ambiguity, with some
kind of qualification syntax to be used if there's another constant of
the same name. There are languages that do this. C, unsurprisingly,
isn't one of them.


What language do you have in mind?


C++ or D?

-atl-
--
A multiverse is figments of its own creations
Nov 14 '05 #16
Ari Lukumies <ar**********@gmail.com> writes:
August Karlstrom wrote:
Keith Thompson wrote:
The language *could* have been defined so that an enumeration constant
can be used without qualification if there's no ambiguity, with some
kind of qualification syntax to be used if there's another constant of
the same name. There are languages that do this. C, unsurprisingly,
isn't one of them.

What language do you have in mind?


C++ or D?


I don't know how C++ deals with this, and there have been several
languages called "D" (I'm not familiar with any of them).

I was thinking of another language whose name is a hexadecimal
palindrome: Ada.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #17
Keith Thompson wrote:
.... snip ...
I was thinking of another language whose name is a hexadecimal
palindrome: Ada.


Ah yes - 2778 (1995) :-)

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 14 '05 #18

In article <ZM*******************@newsb.telia.net>, August Karlstrom <fu********@comhem.se> writes:

Separate enums without lint checking: Worst. My example above
illustrates the problem.


I don't find this example compelling. Enumerations permit both better
naming conventions and separate value ranges; your example is simply
one of poor programmer decisions.

I don't see that you've made any case for the superiority of macro
constants over enumerations under any conditions. (There are some
cases where macro constants can be used but enumerations cannot, for
syntactic reasons, but that's not what we're discussing here.)

--
Michael Wojcik mi************@microfocus.com

Advertising Copy in a Second Language Dept.:
The precious ovum itself is proof of the oath sworn to those who set
eyes upon Mokona: Your wishes will be granted if you are able to invest
it with eternal radiance... -- Noriyuki Zinguzi
Nov 14 '05 #19
mw*****@newsguy.com (Michael Wojcik) writes:
I don't see that you've made any case for the superiority of macro
constants over enumerations under any conditions.


Macro can expand to expressions of types other than `int'.
--
Ben Pfaff
email: bl*@cs.stanford.edu
web: http://benpfaff.org
Nov 14 '05 #20

In article <87************@benpfaff.org>, Ben Pfaff <bl*@cs.stanford.edu> writes:
mw*****@newsguy.com (Michael Wojcik) writes:
I don't see that you've made any case for the superiority of macro
constants over enumerations under any conditions.


Macro can expand to expressions of types other than `int'.


Also not what we were talking about. We were specifically discussing
the cases where either an enumeration or a macro could be used.

--
Michael Wojcik mi************@microfocus.com
Nov 14 '05 #21
Michael Wojcik wrote:
Ben Pfaff <bl*@cs.stanford.edu> writes:
mw*****@newsguy.com (Michael Wojcik) writes:
I don't see that you've made any case for the superiority of
macro constants over enumerations under any conditions.


Macro can expand to expressions of types other than `int'.


Also not what we were talking about. We were specifically
discussing the cases where either an enumeration or a macro
could be used.


And enums yield identifiers that are visible in debuggers, which
macros don't. Enums are much easier to modify when you want a
sequence of identifiers.

Decide how you are likely to change it in the future, and how it
should interact with other things, and then decide how to define
it.

--
Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)
<http://www.dinkumware.com/refxc.html> (C-library}
<http://gcc.gnu.org/onlinedocs/> (GNU docs)
Nov 14 '05 #22

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

12
by: Steven T. Hatton | last post by:
Any opinions or comments on the following? I don't say it below, but I came out on the side of using enumerations over static constants. /* I'm trying to figure out the pros and cons of using...
12
by: Calum Grant | last post by:
In older C++ computer books, you'll often see using namespace std; even in my 1996 copy of Stroustrup. Nowadays, it seems to be considered better to qualify names to make it clearer what...
2
by: msnews.microsoft.com | last post by:
How do I get Intellisense to open a dropdown list box for a method's parameters when the parameter is an ENUM? public class MyClass { public enum IDkind { PersonID, EntityID, PlaceID
36
by: codymanix | last post by:
why do I always have to write the name of the enum type in front of the enum member? why not simply writing Red instead of Color.Red? The compiler always knows which type is expected so there...
2
by: Alex Feldman | last post by:
Which of the following is better? Defining an enum type inside a class as a nested type, or in the the namespace? An example of nested type enumerated type would be: public Class Product...
1
by: Vincent RICHOMME | last post by:
Hi, I would like to know what is the best way of doing the following thing. I am developping a GUI application with a tree and for each item of my tree I can associate(gui mechanism) a class to...
5
by: Jamiil | last post by:
Hey folks! I have declared an enum type inside a name space namespace jme{ enum hero_t{zorro, batmant, cat_woman, other}; class MyClass{ private: hero_t my_hero ..... }; }
13
by: toton | last post by:
Hi, I have some enum (enumeration ) defined in some namespace, not inside class. How to use the enum constant's in some other namespace without using the whole namespace. To say in little...
34
by: Steven Nagy | last post by:
So I was needing some extra power from my enums and implemented the typesafe enum pattern. And it got me to thinking... why should I EVER use standard enums? There's now a nice little code...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.