Use of all-caps *for macros* is still a good idea, because of the
potential they have to do violence to the language syntax and semantics.
Consider, for example:
#define MAX(x, y) ( (x) >= (y) ? (x) : (y) )
The all-caps name makes it clear that something odd could be going on --
in this case, that one of the arguments will be evaluated twice.
There is a simple answer here - don't write code that has side effects
inside function arguments (such as MAX(x++, y++)). Also, avoid writing
general function-like macros that might cause trouble if people /do/
call them with side-effect arguments. With modern C, static inline
functions can replace many function-like macros with a clearer and safer
alternative. And if you really need generic handling of different
types, there are several possibilities (gcc "typeof", C11 _Generic, C++
templates) - although these all have obvious disadvantages.
And it's a well established convention (though one that the standard
library doesn't consistently follow).
It is an established convention, but that does not make it a good thing
(although clearly it has the advantage that people will be unsurprised
by it).
I can find no valid reason - beyond "history" and "convention" - to make
style distinctions:
#define MAX_NUMBER_OF_ITEMS 10
static const int max_number_of_items = 10;
enum { max_number_of_items = 10 };
In most cases, these three identifiers can be used in the same way and
the same places, give the same resulting code, and have the same
compiler-enforced read-only nature. Why should one of them be in
all-caps, making it stand out far too much in the source code?
If I have a piece of code that has a MAX() macro, and I replace the
macro definition with a static inline function, should I go through all
the code and change "MAX(..)" to "max(..)" just because the macro has
turned into a function - even though it does exactly the same thing, and
generates exactly the same code? Conversely, if I want to change an
existing function into a macro do I then need to rename everything in
all-caps just to follow this convention?
I understand that many people use this convention, and I understand that
people think it gives them some sort of warning or protection against
mistakes with macros. I just don't agree with it - at least, not in
/my/ code. (And I know my view here is controversial.)
I agree. For a compiler without _Bool, my favorite way to define a
boolean type is
typedef enum { false, true } bool;
but the whole point of adding <stdbool.h> to the standard library is to
avoid the need to reinvent that particular wheel.
Yes.
There is a significant difference between an enum type and _Bool;
conversion to the latter can only yield 0 or 1 (barring undefined
behavior). Though I try to avoid writing code that depends on that
(more for the sake of clarity than for portability).
Fair enough.
The obvious way to introduce a boolean type to the language would have
been the C++ approach, making bool, false, and true all keywords. But
that would have broken existing code. The existing solution (adding
_Bool as a built-in type, and bool, false, and true as macros in
<stdbool.h>) is probably about the best that could have been done given
that constraint. (Though I would have made bool a typedef rather than a
macro.)
I too would have had bool as a typedef - and false and true as
enumeration constants rather than macros (but as you noted above, bool
itself cannot be an enum). Perhaps the language could have defined
_True and _False as keywords for the type, equivalent to C++'s keywords,
and then put macros in <stdbool.h> to define true and false as _True and
_False rather than 1 and 0. But then the standards people might have
been tempted to say that the values of _True and _False, when converted
to integers, were implementation defined....
