|#include what? DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-04-25)|
|Re: #include what? firstname.lastname@example.org (Russ Cox) (2006-04-26)|
|Re: #include what? email@example.com (Ian Lance Taylor) (2006-04-27)|
|Re: #include what? cfc@shell01.TheWorld.com (Chris F Clark) (2006-04-27)|
|Re: #include what? firstname.lastname@example.org (glen herrmannsfeldt) (2006-04-28)|
|Re: #include what? email@example.com (2006-04-28)|
|Re: #include what? cfc@shell01.TheWorld.com (Chris F Clark) (2006-04-30)|
|Re: #include what? DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-05-09)|
|From:||Ian Lance Taylor <firstname.lastname@example.org>|
|Date:||27 Apr 2006 09:12:03 -0400|
|Posted-Date:||27 Apr 2006 09:12:03 EDT|
"Russ Cox" <email@example.com> writes:
> #includenext, which is even-more gcc-specific, makes gcc start the search
> where the search for the current file left off. This way you could
> create your own wrapper around (say) <stdio.h> that was actually
> called stdio.h and did something like
> #includenext <stdio.h>
> void newfunction(FILE*);
> Using includenext keeps gcc from finding the current file again.
> I can't imagine why you would ever use this.
As you say, you use #include_next (with underscore) if you are
wrapping a library. There are several reasons to do this. One
typical one is that you have to use an old library, you can't change
the library source code for some reason, but you do want to add
additional macros and declarations which programs expect.
For example, gcc does this with <limits.h> on some systems: gcc
provides a <limits.h> which does a #include_next <limits.h> to pick up
the system <limits.h>, and then defines versions of the ISO C macros,
like INT_MAX, etc., which are appropriate for gcc.
Return to the
Search the comp.compilers archives again.