using macros ...

[hasadh]

Hello,

probably this may be a simple qn to u all but I need an answer plz.
In my software i used macros like OK,TRUE,FALSE,FAILURE . A friend who
included this code as a library into his module said that in his code
he couldnt use the above words as function names or variable names and
got compilation errors. He advised me to use them as enums instead of
macros. is he right ???

(in my code the macros are used as return values from fns mostly)

awaiting your replies.

regards,
prakas

 

[Joona I Palaste]

Hello,

probably this may be a simple qn to u all but I need an answer plz.
In my software i used macros like OK,TRUE,FALSE,FAILURE . A friend who
included this code as a library into his module said that in his code
he couldnt use the above words as function names or variable names and
got compilation errors. He advised me to use them as enums instead of
macros. is he right ???

(in my code the macros are used as return values from fns mostly)

awaiting your replies.

If this is some kind of debate, I'm willing to take your side on this.
Your friend is correct that he can't use OK, TRUE, FALSE or FAILURE as
variable or function names, but why should he? It's a common spelling
convention that variable and function names are in lower case and macro
names are in upper case.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"When a man talks dirty to a woman, that's sexual harassment. When a woman talks
dirty to a man, that's 14.99 per minute + local telephone charges!"
- Ruben Stiller

 

[Ravi]

probably this may be a simple qn to u all but I need an answer plz.
In my software i used macros like OK,TRUE,FALSE,FAILURE . A friend who
included this code as a library into his module said that in his code
he couldnt use the above words as function names or variable names and

BTW you define macros like this
#define TRUE 1
etc.
and after that you would not use them as function name

OTOH
#define printf PRN
and then you may use PRN as a function name.

got compilation errors.

Which compiler? What did you do, some more details

He advised me to use them as enums instead of
macros. is he right ???

Was he trying to say this would solve the problem with
compilation?

 

[Guest]

Hello Joona I Palaste,

It's a common

spelling

Oh! really?

 

[Ravi]

BTW you define macros like this
#define TRUE 1
etc.
and after that you would not use them as function name

OTOH
#define printf PRN

#define PRN printf

sorry, happens!

 

[Joona I Palaste]

Hello Joona I Palaste,

I have no clue as to what you are meaning with your question.

 

[E. Robert Tisdale]

In my software, I used macros like OK, TRUE, FALSE, FAILURE.
A friend who included this code as a library into his module
said that, in his code, he couldn't use the above words
as function names or variable names and got compilation errors.
He advised me to use them as enums instead of macros.
Is he right?

The problem is name space pollution.
Your definitions of global names conflict with other definitions.
This problem is easily solved by prepending a unique prefix
to all of the global names in your module:

#define moduleName_OK 1
#define moduleName_FALSE 0
#define moduleName_TRUE (!(moduleName_FALSE))
#define moduleName_SUCCESS 0
#define moduleName_FAILURE (!(SUCCESS))

C preprocessor macros are dangerous.
An enumeration or, better yet, const global objects are much safer.

 

[E. Robert Tisdale]

It's a common spelling convention that
variable and function names are in lower case
and macro names are in upper case.

Which is an anachronism now that the const keyword
and inline functions have been introduced into the language.

 

[Guest]

Hello Joona I Palaste,

I have no clue as to what you are meaning with your question.

I was just ranting. You don't call that a 'spelling' convention I guess
If I'm wrong please correct me.

 

[Eric Sosman]

The problem is name space pollution.
Your definitions of global names conflict with other definitions.
This problem is easily solved by prepending a unique prefix
to all of the global names in your module:

#define moduleName_OK 1
#define moduleName_FALSE 0
#define moduleName_TRUE (!(moduleName_FALSE))
#define moduleName_SUCCESS 0
#define moduleName_FAILURE (!(SUCCESS))

C preprocessor macros are dangerous.
An enumeration or, better yet, const global objects are much safer.

Why in the world should the programmer's use of the
identifiers reserved for the programmer be called "name
space pollution?" Or to put it another way: What is
there about the identifier `moduleName_OK' that makes it
one whit less "polluting" than `OK'?

C preprocessor macros are dangerous -- in the wrong
hands, as are all C constructs. The error in the example
above suggests that ERT's hands may not be the right ones,
and may go some ways toward explaining why he finds macros
dangerous. Programmers who deploy a little more skill and
a little more care will find macros both safe and helpful.

 

[Jeffrey D. Smith]

BTW you define macros like this
#define TRUE 1
etc.
and after that you would not use them as function name

OTOH
#define printf PRN
and then you may use PRN as a function name.


Which compiler? What did you do, some more details



Was he trying to say this would solve the problem with
compilation?

Yes it will. Changing to enums will avoid the
preprocessor substitution. The compiler can
see the enum symbols and distinguish them from
other uses (like function calls).

 

[CBFalconer]

Which is an anachronism now that the const keyword
and inline functions have been introduced into the language.

Don't spout nonsense and corrupt the children. Those have quite
distinct uses, and cannot substitute for macros.

 

[CBFalconer]

The problem is name space pollution.
Your definitions of global names conflict with other definitions.
This problem is easily solved by prepending a unique prefix
to all of the global names in your module:

#define moduleName_OK 1
#define moduleName_FALSE 0
#define moduleName_TRUE (!(moduleName_FALSE))
#define moduleName_SUCCESS 0
#define moduleName_FAILURE (!(SUCCESS))

C preprocessor macros are dangerous.
An enumeration or, better yet, const global objects are much safer.

This is bad advice, and indicative of failure to limit access to
the narrowest possible scope and failure to understand the
language.

 

[Jeremy Yallop]

Which is an anachronism now that the const keyword
and inline functions have been introduced into the language.

Not at all. There are lots of things that are possible to achieve
with macros, but impossible with const and inline functions. In fact,
although inline functions can occasionally be used in place of macros,
const cannot generally be used to replace #define-d symbolic
constants, since the value of a const variable cannot be used in a
constant expression.

This has been explained to you before, but you continue to spread the
same misinformation. Please stop.

http://groups.google.com/[email protected]
http://groups.google.com/[email protected]

Jeremy.

 

[Jeremy Yallop]

Which is an anachronism now that the const keyword
and inline functions have been introduced into the language.

Not at all. There are lots of things that are possible to achieve
with macros, but impossible with const and inline functions. In fact,
although inline functions can occasionally be used in place of macros,
const cannot generally be used to replace #define-d symbolic
constants, since the value of a const variable cannot be used in a
constant expression.

This has been explained to you before, yet you continue to spread the
same misinformation. Please stop.

http://groups.google.com/[email protected]
http://groups.google.com/[email protected]

Jeremy.

 

[Richard Bos]

The problem is name space pollution.

C preprocessor macros are dangerous.
An enumeration or, better yet, const global objects are much safer.

So, erm... please explain how, exactly,

enum predefined_values {no, yes};

is any less namespace-polluting than

#define NO 0
#define YES 1

Richard

 

[Alex]

The compiler can see the enum symbols and distinguish them from other
uses (like function calls).

No it can't, although a name clash with an enum constant will probably give
a less confusing error message, eg:

#define foo 42
int foo(void) {
return 42;
}

test.c:2: parse error before numeric constant

enum {foo = 42};
int foo(void) {
return 42;
}

test.c:2: `foo' redeclared as different kind of symbol
test.c:1: previous declaration of `foo'

Alex

 

[pete]

Hello,

probably this may be a simple qn to u all but I need an answer plz.
In my software i used macros like OK,TRUE,FALSE,FAILURE . A friend who
included this code as a library into his module said that in his code
he couldnt use the above words as function names or variable names and
got compilation errors. He advised me to use them as enums instead of
macros. is he right ???

(in my code the macros are used as return values from fns mostly)

awaiting your replies.

About the only use I've ever had for enums,
is as return values from functions.
I think they're OK for that purpose.

 

[hasadh]

Hi,

you say that "The compiler can see the enum symbols and distinguish them from
other uses (like function calls)." .
but i get compilation error if i use a enum symbol and a same fn name. eg
enum {TRUE 1}

and
void TRUE() - gives compilation error in vc++ .

 

[Joona I Palaste]

Hi,

you say that "The compiler can see the enum symbols and distinguish them from
other uses (like function calls)." .
but i get compilation error if i use a enum symbol and a same fn name. eg
enum {TRUE 1}

and
void TRUE() - gives compilation error in vc++ .

True, true... (pun not intended), but like I said in my previous reply,
why would anyone *want* to name their function "TRUE"?