enumerations

[InuY4sha]

if I have 2 files (say foo1.c and foo2.c) which link within the same
application, can I use 2 enumerations with the same names?
Example:

//foo1.c
typedef enum{
HELLO_WORLD,
SPECIFIC_NUM1
}foo1_enum;

//foo2.c
typedef enum{
SPECIFIC_NUM2,
HELLO_WORLD
}foo2_enum;

Does it complain for the HELLO_WORLD enumeration?

 

[Eric Sosman]

if I have 2 files (say foo1.c and foo2.c) which link within the same
application, can I use 2 enumerations with the same names?
Example:

//foo1.c
typedef enum{
HELLO_WORLD,
SPECIFIC_NUM1
}foo1_enum;

//foo2.c
typedef enum{
SPECIFIC_NUM2,
HELLO_WORLD
}foo2_enum;

Does it complain for the HELLO_WORLD enumeration?

Not if they're in separately-compiled files, no. The
identifiers declared here have no linkage, so they are not
"visible" outside their respective scopes.

 

[InuY4sha]

If you don't export the symbols they have file scope, so the fact that you
link won't cause a complaint. However usually you would want an enum in a
header. There you would get a clash if you included both. Unfortunately C
isn't clever enough to match up the enum symbol to the type of variable
holding it.

Thanks (to Eric too),
the reason for my question is that I need a way to describe exceptions
by means of an enumeration. BUT, when I change file I can have some
exception that are generic and hence preserved, while others do not
fit for the new kind of data structure described by a file...

Maybe I can explain even better if I tell you the whole thing in mind:
I'd like a way to track exception and the SOURCE FILE / FUNCTION where
those happened. What I do now is the following define for each file:
(Given the filename is foo.c):

#define foo_exception(foo_enum e) (exception("foo.c", (unsigned int)
e))

 

[Nobody]

if I have 2 files (say foo1.c and foo2.c) which link within the same
application, can I use 2 enumerations with the same names?
Example:

//foo1.c
typedef enum{
HELLO_WORLD,
SPECIFIC_NUM1
}foo1_enum;

//foo2.c
typedef enum{
SPECIFIC_NUM2,
HELLO_WORLD
}foo2_enum;

Does it complain for the HELLO_WORLD enumeration?

Enumerators are constants. They don't appear as symbols in the object
file, so there won't be a linking conflict.

If you were to put the types into header files, and include both headers
from the same source file, then you would get an error during compilation.

 

[David Thompson]

If you don't export the symbols they have file scope, so the fact that you
link won't cause a complaint.

If by 'export' you mean 'give external linkage', you can't do that at
all for enum-values, or enum struct or union types or typedefs. They
don't even exist at link time in the usual separate-compilation model.
Only (some) objects (variables), and functions, have either internal
OR external linkage.

However usually you would want an enum in a
header. There you would get a clash if you included both.

If you want enums/types, or macros, shared across multiple translation
units, you have to put them in a (shared) header, or otherwise
duplicate the text (e.g. in your source-control system).

I'm not sure about 'usually' though. If the enum is part of the
interface to other modules, yes it belongs in .h. If it is only used
in the implementation, it's perfectly sensible in .c. IME (not
statistically valid) both occur, I would estimate about equally.

Unfortunately C
isn't clever enough to match up the enum symbol to the type of variable
holding it.

For enum-values, yes. For enum-types, sort of; in C (unlike C++) they
are only aliases for builtin integer types, but different enum types
MAY be different integer types, so the object type is affected by the
enum type. But many (most?) compilers don't bother and just use int.

And since most (symbolic) debuggers treat all symbols as global, or at
least all file-scope ones, even having the different enums in
different t.u.s, which is fine for compile and link, will cause chaos
in debugging -- if you use a debugger, which is a FArguedQ <G?>.