Walter Roberson wrote:
In article <44***********************@news.xs4all.nl>,
Skarmander <in*****@dontmailme.com> wrote: And if I'm reading you correctly, you're putting code in a header. Don't do
that. Headers should be used for declarations only.
That's a matter of style, not any restriction or recommendation of
the C language itself.
Of course. The phrase "don't do that" usually signals an opinion on style.
"You can't do that" would be a language restriction.
If one had a static function (i.e., file scope) that was used in several
places, I'm not sure that it would make much difference whether
one put the code into a file that was included where needed,
compared to if one put a #define of all of the code into a header
and then explicitly called upon the macro to define the function.
Using the macro version requires using continuation lines all
over the place, and would not allow for the possibility of
conditional compilation in the function definition.
The first thing that springs to mind is that a function with file scope that
is used in several places is a contradiction in terms, but of course this is
not true; the odd situation is a consequence of C's approach to modularity
being restricted to files. One could have a library where externally visible
functions in different files needed to call a function that should not be
externally visible.
I'd argue that linkers are supposed to solve this problem, even if "linking"
is not part of the C language. One benefit to a solution through a linker is
that there really is only one function, not one function copied many times.
(This discussion is orthogonal to inline functions, which can also be
implemented by putting code in headers, and also have alternate approaches.)
But assuming linker magic isn't a solution, I do agree that #including the
function definition is cleaner than using a macro. I don't think that using
a macro is better just because it's supposed to get around the "don't put
code in a header" recommendation. The point of that recommendation is to
encourage people to have a clean split between interfaces and
implementations. You can do that even when you put code in a header, if you
know what you're doing.
It's comparable to "don't use goto". There will be circumstances where the
most appropriate course of action is to use goto, but if you can recognize
them you don't need the recommendation. All that is intended is to
discourage people from doing it arbitrarily.
S.