🚀 go-pugleaf

girod@dshp01.trs.ntc.nokia.com (Marc Girod) writes:

>In article <48ta6u$5c2@engnews1.eng.sun.com>
>clamage@Eng.sun.com (Steve Clamage) writes:

>>>>>> "SC" == Steve Clamage <clamage@Eng.sun.com> writes:

>SC> No. But you should use <header> for system headers and "header" for
>SC> your own headers. The two notations have implementation-defined
>SC> semantics, and implementations traditionally use different search
>SC> methods so that a system header will not override a project header,
>SC> and vice versa.

>I was myself recommending to users in my project to resort to one and
>only one include syntax (that is #include <...>), under the rationale
>that:

>The location of the included files is a configuration management
>concern and should be taken care in the makefile. Extra-linguistic
>features should be used only as few as possible.

>Would you comment on that?

The language defines two syntaxes for inclusion: enclosing the header
in "" and in <>, so I would say that taking advantage of that would
be inside, not outside, the language.

Strictly speaking, the exact meaning of the two forms can vary from
system to system, so to some extent you are open to different results.
But the meaning of
	#include <myhdr.h>
varies from system to system as well.

The reason for the two forms of include is, I believe, to reduce
the chances of header conflict. For example, the usual rule is
to look for "" headers first in the "current" directory, then in
"standard" locations. The usual rule for <> headers is to ignore
the "current" directory.

Any project header name runs the risk of colliding with a system
header name on one system or another. To prevent one from
incorrectly hiding the other, it helps to have two forms of include:
	#include <foo.h> // get the system header
	#include "foo.h" // get the project header
The first form might appear nested in a system header, and you might
not be aware that it existed on the machine at all. If you use only
one form of include, one header will always hide the other.
--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]