«

I firmly believe that it is always a bad idea to put code in a header
file. Nothing ****es 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?

bill wrote:
> 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 ****es 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.

--
Peter

Pigpen wrote:

> I firmly believe that
> it is always a bad idea to put code in a header file.
> Nothing ****es 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.

bill <> a écrit*:
> 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