assertion in header

[bill]

I firmly believe that it is always a bad idea to put code in a header
file. Nothing pisses me off more than seeing function definitions in a
..h, and I recently was truly blessed to witness code that actually
contained #include "foo.c" in a header. However, I am eliciting
responses to the thought of putting assertions in a header file. I am
dealing with a really ugly, really poorly done code base, and I find
myself often thinking "wtf? Does this mean what I think it does?" In
such cases, I usually like to trow in an assertion to confirm things.
My aesthetic sense tells to clean out all of the header files, my
realistic sense tells me to dump the whole thing and start over, but my
practical sense tells me that either of those solutions will take
months. So I'm putting assertions into header files, and it makes me
feel dirty. Am I compounding an already horrible situation? When
possible, I use:
#if FOO != BAZ
#error
#endif
but in a case where the header already has run-time code, I need to use
an assertion. Believe me, I would love to simply pull the code out of
the headers, but the build environment is so phenomenally convoluted
that changing the file structure is a major headache. I suppose that
in this situation, aesthetics and good style are totally pointless
concerns, but I still have some dignity.

So, what do you think. Is it acceptable to put an assertion into a
header file?

 

[Peter Nilsson]

I firmly believe that it is always a bad idea to put code in a header
file.

Depends what you mean by 'code'. Empty headers are pretty pointless.

[If you're entering thousands of enum identifiers by hand, and you're
paid per line of code, and enums aren't considered code, ... then you
should get another job. ;-]

Nothing pisses me off more than seeing function definitions in a
.h, and I recently was truly blessed to witness code that actually
contained #include "foo.c" in a header.

How is this 'better' than having the code directly in the header?

However, I am eliciting responses to the thought of putting assertions
in a header file. ... I usually like to trow in an assertion to confirm
things.
My aesthetic sense tells to clean out all of the header files, my
realistic sense tells me to dump the whole thing and start over, but
my practical sense tells me that either of those solutions will take
months. So I'm putting assertions into header files, and it makes me
feel dirty. Am I compounding an already horrible situation? When
possible, I use:
#if FOO != BAZ
#error
#endif

How does this relate to function definitions in headers?

but in a case where the header already has run-time code, I need to
use an assertion.

How? If you make inclusions of those headers errors, then you're
just screwing your entire build.

Are you suggesting that (true) source (.c) files have something like...

#define INCLUDE_HEADER_SOURCE 1

....and your header functions are wrapped with #if/endif?

Believe me, I would love to simply pull the code out of the headers,
but the build environment is so phenomenally convoluted that changing
the file structure is a major headache.

I don't really see why you can't change the function definitions into
declarations only, and move the source into a single extra translation
unit, however, if the headers have header guards, just change the
functions to static scope. [That will magnify your executable size,
but it's the laziest option available.]

I suppose that in this situation, aesthetics and good style are
totally pointless concerns, but I still have some dignity.

Depends what price you value your dignity. If it's your name on the
code, and you're asking other people to continue the maintenance, then
not doing it right is just false lazyness.

So, what do you think. Is it acceptable to put an assertion into a
header file?

Perfectly, but you haven't really explained how you will apply your
'assertions'. Perhaps you could supply an shortened sample of what
you are really facing.

 

[E. Robert Tisdale]

I firmly believe that
it is always a bad idea to put code in a header file.
Nothing pisses me off more than seeing function definitions in a .h
and I recently was truly blessed to witness code
that actually contained #include "foo.c" in a header.

You are confused.
All that is meant by the term "header file" is that
it is meant to be included somewhere near the top (head)
of a source file or another header file.

Header files are commonly used to introduce a *module interface*
into a translation unit. An interface has no substance.
This means that it should *not* contain any definitions
that, by themselves, cause the compiler to emit code or reserve memory.
Any such definitions should be sequestered in a translation unit
which can be compiled separately and linked into the program.

Good C programmers often *do* use the C preprocessor to include
files that contain external function and variable definitions
where they are required in the translation unit.
They probably should *not* call them header files
because other C programmers may think that
they contain a module interface.

However, I am eliciting responses
to the thought of putting assertions in a header file.
I am dealing with a really ugly, really poorly done code base
and I find myself often thinking,
"Wtf? Does this mean what I think it does?"
In such cases, I usually like to throw in an assertion to confirm things.
My aesthetic sense tells to clean out all of the header files.
My realistic sense tells me to dump the whole thing and start over.
But my practical sense tells me that
either of those solutions will take months.

Does this code belong to you now?
Are you responsible for maintaining and extending the code?
If it belongs to someone else,
you should try to get them to fix and maintain it.
If it belongs to you,
you need to make a plan to fix it no matter how long it takes.

So I'm putting assertions into header files and it makes me feel dirty.

A cold shower might help.

Am I compounding an already horrible situation?
When possible, I use:

#if FOO != BAZ
#error
#endif

but, in a case where the header already has run-time code,
I need to use an assertion.
Believe me, I would love to simply pull the code out of the headers
but the build environment is so phenomenally convoluted
that changing the file structure is a major headache.
I suppose that, in this situation,
aesthetics and good style are totally pointless concerns.
but I still have some dignity.

So, what do you think.
Is it acceptable to put an assertion into a header file?

I can only assume that you mean the assert macro.
Whether they appear in a header file or not is irrelevant.
Any assert macros must appear in the scope of a function definition.
They are used to trap programming errors at run-time while testing.
They disappear when you define the NDEBUG macro and recompile
just before you deploy your code.

 

[Marc Boyer]

but in a case where the header already has run-time code, I need to use
an assertion.

I do not understand what you mean with "run-time code in header".
Could you please gives an example ?

Marc Boyer