* But all of these things can be done in a C header file. So all we *need* is the ability to include a single header file, gotten from the current directory
foo.h
We don't want to force you to write a wrapper header file in the case where it would just contain a single #include and nothing else - just cut out the middle man and write the name of the include file you really wanted in the first place. But this requires allowing <> style includes (I guess - I admit I'm not up on the precise meaning of <> vs ""). Cheers, Simon
"Simon Marlow" <simonmar@microsoft.com> wrote,
* But all of these things can be done in a C header file. So all we *need* is the ability to include a single header file, gotten from the current directory
foo.h
We don't want to force you to write a wrapper header file in the case where it would just contain a single #include and nothing else - just cut out the middle man and write the name of the include file you really wanted in the first place. But this requires allowing <> style includes (I guess - I admit I'm not up on the precise meaning of <> vs "").
No, it does not necessarily require <>. If you write #include "foo.h" the C compiler will *also* look in all places where it would look for #include <foo.h> The only case where <> is needed is where there are two versions of `foo.h'. One where only "foo.h" will find it and one in the system search path used by <foo.h>. In this case, "foo.h" and <foo.h> will find different versions. So, it all boils down to the question of whether this (probably rare) case justifies the (not very large) extra complexity of allowing header file names enclosed in <>. I am happy either way, but slightly tend to the simpler solution (not allowing <>). Would everybody who prefers to have <> please say so and briefly say why? Thanks, Manuel
On Wed, May 30, 2001 at 22:59:37 +1000, Manuel M. T. Chakravarty wrote:
So, it all boils down to the question of whether this (probably rare) case justifies the (not very large) extra complexity of allowing header file names enclosed in <>.
I am happy either way, but slightly tend to the simpler solution (not allowing <>). Would everybody who prefers to have <> please say so and briefly say why?
Sorry for dropping into the discussion, but... Using "" instead of <> once caused me some problems (can't recall what it was in particular). However, since then my standard was to always use <> and handle the "" case by adding -I. parameters... That would also have the benefit of being somewhat less dependant on the behaviour of a implementation (as somebody quoted from the standard). If you put -I. in front, it will always get searched before include dirs given by subsequent -I options, right? Cheers, Michael -- () ASCII ribbon campaign | Chair for Computer Science II | GPG: F65C68CD /\ against HTML mail | RWTH Aachen, Germany | PGP: 1D0DD0B9 "I WILL NOT SELL SCHOOL PROPERTY" -- Bart Simpson in 7F10
Michael Weber <michael.weber@post.rwth-aachen.de> wrote,
On Wed, May 30, 2001 at 22:59:37 +1000, Manuel M. T. Chakravarty wrote:
So, it all boils down to the question of whether this (probably rare) case justifies the (not very large) extra complexity of allowing header file names enclosed in <>.
I am happy either way, but slightly tend to the simpler solution (not allowing <>). Would everybody who prefers to have <> please say so and briefly say why?
Sorry for dropping into the discussion, but...
You are always welcome, Michael :-)
Using "" instead of <> once caused me some problems (can't recall what it was in particular). However, since then my standard was to always use <> and handle the "" case by adding -I. parameters... That would also have the benefit of being somewhat less dependant on the behaviour of a implementation (as somebody quoted from the standard). If you put -I. in front, it will always get searched before include dirs given by subsequent -I options, right?
This is not guaranteed by the standard. The ISO C99 standard (as quoted by Fergus earlier) says for <> [..] searches a sequence of implementation-defined places [..] How the places are specified [..] is implementation-defined. However, the standard does guarantees for "" that The named source file is searched for in an implementation-defined manner. If [..] the search fails, the directive is reprocessed as if it read # include <h-char-sequence> new-line So, it seems that using "" is more portable than using <> in conjunction with -I. I will leave it with "" as the only option, then. Cheers, Manuel
participants (3)
-
Manuel M. T. Chakravarty -
Michael Weber -
Simon Marlow