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 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. 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 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 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
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 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
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.
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?
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.
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
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.
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
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.
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
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
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.
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
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 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
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
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) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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...
|
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
|
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...
|
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...
|
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...
|
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
.....
};
}
|
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...
|
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...
|
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...
|
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...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
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...
|
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...
|
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)...
|
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...
|
by: Defcon1945 |
last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
|
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....
| |