OK to disguise a macro function as a function?




I'm not a fan of ALL CAPS, but of course I use it for macro
functions to warn the programmer to be picky about what arguments they
pass (for fear of multi-evaluation).

However, I wonder what people think about _not_ using all caps when
the macro function doesn't have any parameters, or when the arguments
won't be multi-evaluated? For instance, in my own code, instead of
having:

inline void RowPinHigh(unsigned const i) { PORTA |= 1u << i; }

, I have the following:

#define RowPinHigh(i) ((void)(PORTA |= 1u << (i)))

Firstly, the argument will only be evaluted once, so there's no
problems on that front. The only other problem I can see is the issue of
being able to take the function's address; I already ran into this
problem in my own code:

void (*RowPinAssert)(unsigned) = (first_pass ? RowPinHigh :
RowPinLow);

Still though, this isn't really so much a problem in that it will
introduce bugs -- you'll simply get a compile error saying RowPinHigh
wasn't declared (or perhaps if your compiler is set to Ancient Mode, a
linker error saying a function called RowPinHigh that returns int
couldn't be found).

Currently I'm using an embedded systems compiler for programming
microcontrollers, and it's not exactly 100% ANSI-compliant so I've had
to do a few things such as:
1) Use macros fuctions instead of inline functions (this actually
_does_ result in my code being smaller and actually fitting onto the
chip's memory).
2) Use global variables instead of local variables in some instances
because there's no stack (another strategy to save memory). I haven't
tried using recursive functions but my bet is they don't work because
static memory is used instead of a stack.

Also, the compiler is very particular about what it considers const.
For instance, you _can_ do the following:

void Func(void)
{
int const i = 7;
}

, but you _can't_ do this:

void Func(int x)
{
int const i = x; /* Compile Error */
}

The reason it gives a compile error is because when it sees the word
"const", it assumes it can store it in read-only memory, i.e. a part of
memory in the chip that can't be written to while the program is
running. Therefore, you can't use const in the example immediately
above.
However, given that I didn't want to pick up the habit of omitting
const, I decided to do the following instead:

#define immutable

void Func(int x)
{
int immutable i = x;
}

, and from there I use "const" when something is trully read-only, and
"immutable" when I just don't want to change it. Then if I migrate my
code to another system, I can just do:

#define immutable const

And if even that's too disgusting for some programmers, I can always do
a "Find and Replace in all files" to change immutable to const.

But anyway... back to the topic at hand, what do you think about _not_
using all caps when there's no parameters or when the parameters won't
be multi-evaluated?

--
Tomás Ó hÉilidhe
.



Relevant Pages

  • Re: const
    ... > const modifiers, ... willing to remove the const'ness with a cast, ... I don't know how good a cross-file compiler could be - it would have to be ... it's a guarantee by the programmer. ...
    (comp.programming)
  • Re: Making C better (by borrowing from C++)
    ... is actually needed often allows you to declare it const (if it is ... increased opportunities for compiler optimization. ... without programmer assistance. ... lapse and mixing up the order of the arguments to memcpy(). ...
    (comp.lang.c)
  • Re: Code density and performance?
    ... >>transparently in the compiler and libraries. ... > 2) There is NOTHING that the programmer can do to force it. ... Heck, IPF memory requirements make ... > You may regard breaking standards without even documenting the ...
    (comp.arch)
  • Re: Is const really const?
    ... Rohit kumar Chandel wrote: ... change the value of a const variable. ... Compiler tries its best to keep the ... promise,by not allowing programmer modify the const variable directly (p++ ...
    (comp.lang.c)
  • Re: question on const
    ... >> declared to be const, because the compiler is allowed to assume that ... > The compiler is allowed to assume that the value it's not changed, ... The programmer who wrote that code deserves a kick in the ***. ...
    (comp.lang.c)