New coding standards: use underscores, hyphens or mixed case in command (and identifier) names

[Ronald Landheer-Cieslak]

But not the other way round: if the maintainer fails to realise that the
identifier is a constant that could be used in a constant expression,
there is no one to tell him about it.

I the maintainer fails to realize that a constant is a constant from the
name of the variable, which, I repeat, should be named for its
functionality, then the variable is probably not named clearly enough.
Failing that, you may have a point

In C, there is more than way of defining such constants:

#define MAXVAL 1000 /* MAXVAL can be used in constant expressions */
vs
const int maxval = 1000; /* no maxval in constant expressions */

Yeah, that would be a quirk in C.. The following makes your point nicely:
http://www.embedded.com/story/OEG20011220S0063

IMHO, C++ is right here: a constant expression should accept *any*
constant (i.e. anything of which the value is known at compile-time).

Even if you don't need them, they certainly help. Have a look at the
constants defined in <limits.h> and <float.h> and see how many of them
aren't all caps.

I do not necessarilly concur with all the choices the committee-people
make - especially where style is concerned.

That said, the first two of the three points you made seem pertinent
enough to concur w/ naming
constants-suitable-for-use-in-constant-expressions in all-caps. That
would go for #defined constants and enums..

Still not convinced for macros, though (even though I usually do name
them in all-caps, BTW ).

rlc

 

[Keith Thompson]

An inline function would have been a better way to do that and since
they exist since C99, why not use them and declare macros that
evaluate their parameters more than once a no-no..?

That's fine if you can assume that your code will only be compiled
with C99 compilers (or at least with compilers that implement inline
functions with C99-compatible syntax and semantics). That's not
always a safe assumption.

 

[Richard Bos]

Almost convincing

Thing is: macros that evaluate their parameters more than once are evil:
they shouldn't be written in the first place.

In theory, I agree. In practice, please write a swap macro without
evaluating at least one of the parameters more than once.

Richard

 

[Dan Pop]

An inline function would have been a better way to do that and since
they exist since C99, why not use them and declare macros that evaluate
their parameters more than once a no-no..?

Clue: function-like macros can do things functions (inline or not) cannot
do. Write the function implementing the functionality of the following
macro:

#define MIN(n1, n2) ((n1) < (n2) ? (n1) : (n2))

Dan

 

[Dan Pop]

Erhm.. let's see:
^^^^^^^^^^^^^^^^^^^^^^^
I guess that would be me

The semantics of this idiomatic question are: what are your credentials?

In my experience, one can hardly ever rely on a naming convention to be
followed correctly & completely.

In my experience, competent programmers never break a naming convention
without a *good* reason.

That aside, if you have to look up the semantics of your macros every
time you use them, just because they're macros, don't you think you're
kinda defeating the purpose of your macro?

Nope, you simply assume that each and every parameter can be multiply
evaluated. Even if this is not the case NOW, it might be in a future
version of the macro.

In most cases, inline functions would do just as nicely without the
trouble that macros can cause (and C99 allows them, so why not use them?)

1. Because I have no conforming C99 compiler.

2. Because macros can do things functions cannot. I have already provided
an example, in another post in this thread.

Dan

 

[Ronald Landheer-Cieslak]

[...]


Thing is: macros that evaluate their parameters more than once are
evil: they shouldn't be written in the first place. Basically, macros
that have different semantics than their equivalent functions are
confusing and therefore harmful.

Macros *can* be good, but some *definitely* aren't.

I think that's over-stating it a bit.
Macros that evaluate their parameters more than once impose a cost in
terms of maintainability. But there are circumstances in which that
cost is worthwhile. The getc macro in <stdio.h> is a good example of
this; by allowing the stream argument to be evaluated more than once,
it saves the overhead of a function call in most cases.
(An inline function might have been a better way to do this, but C
didn't have inline functions before C99.)

An inline function would have been a better way to do that and since
they exist since C99, why not use them and declare macros that
evaluate their parameters more than once a no-no..?

That's fine if you can assume that your code will only be compiled
with C99 compilers (or at least with compilers that implement inline
functions with C99-compatible syntax and semantics). That's not
always a safe assumption.

Granted, in which case function-like macros are a necessary evil

rlc

 

[Ronald Landheer-Cieslak]

Keith Thompson wrote:

[...]


Thing is: macros that evaluate their parameters more than once are
evil: they shouldn't be written in the first place. Basically, macros
that have different semantics than their equivalent functions are
confusing and therefore harmful.

Macros *can* be good, but some *definitely* aren't.


I think that's over-stating it a bit.

Macros that evaluate their parameters more than once impose a cost in
terms of maintainability. But there are circumstances in which that
cost is worthwhile. The getc macro in <stdio.h> is a good example of
this; by allowing the stream argument to be evaluated more than once,
it saves the overhead of a function call in most cases.

(An inline function might have been a better way to do this, but C
didn't have inline functions before C99.)

An inline function would have been a better way to do that and since
they exist since C99, why not use them and declare macros that evaluate
their parameters more than once a no-no..?

Clue: function-like macros can do things functions (inline or not) cannot
do. Write the function implementing the functionality of the following
macro:
#define MIN(n1, n2) ((n1) < (n2) ? (n1) : (n2))

In C, that is impossible, but that doesn't change that, IMHO, C is
broken in this respect.

Again, a necessary evil in this case, but *only* in case you actually
*need* a "function" that can basically take any type as parameter, which
IMHO is (or should be) rarely the case (or in which case you just might
need a different language, such as C++).

Now, don't get me wrong: I can understand that you may need such macros
from time to time, and in the cases where the macros evaluate their
parameters more than once, IMHO, the maintainer should be notified in
some way (i.e. by naming the macro in all-caps, for example).

The point I'm trying to make is:
* one should avoid writing macros that evaluate their parameters more
than once
* there is no reason to name *all* macros in all-caps (but that doesn't
mean that *none* should be named in all-caps

rlc