Re: Include Collector (may be OT)
On 27-Jul-00, 02:13 (CDT), Ulrich Eckhardt <Doomster@knuut.de> wrote:
> On Thu, 27 Jul 2000, Bolan Meek wrote:
> >
> > I want an
> > #include "project.h" in each of these files, project.h containing
> > #include <stdio.h>
> > #include <unistd.h>
> > and ruleworld.c to still have the unique inclusion, in addition to
> > the common inclusion.
> >
> On the risk of being even more off the topic of your post:
> You don't want this !
I generally agree with Ulrich's points, but have few comments.
It can be justified if you if you're mixing and matching header files
depending on platform (Unix vs. OpenVMS vs. NT, for example), and don't
want to duplicate the macro checks and if-then-else logic in each source
file, but that doesn't apply to C standard library stuff.
It can be justified if you have pre-compiled headers, and it's very
important that you have the same headers in the same order to keep that
from breaking.
> If I only needed printf, I would even consider just giving the
> prototype and not including the header at all (but I have no idea what
> drawbacks might arise from this,eg portability, changing headers).
Ack. Don't do this. The standard just barely allows this, and only
if certain conditions are met (I don't think you can do it for
printf(), for example, and definitely not for fprintf()), but it's a
portability/reliability nightmare. It's not worth the few milliseconds
of saved compile time. It can be a bad performance tradeoff too: a lot
functions are (or at least can be) implemented as inline macros, which
you'll lose if you do your own declarations.
In fact, IMNSHO it's a bad idea to do so even for your own code. When I
write a function that is used in another module, the prototype goes in a
header, and the header gets included by both the module that uses it and
the module that defines it. It may sound like a hassle, but you'll thank
yourself when you change the definition and forget to change the header
or the invocation.
Steve
Reply to: