Topic: New STD header format (no extension),
Author: "brian (b.c.) white" <bcwhite@bnr.ca>
Date: 1995/11/28 Raw View
In article <GIROD.95Nov23150453@dshp01.trs.ntc.nokia.com>,
Marc Girod <girod@trshp.trs.ntc.nokia.com> wrote:
>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.
Personally, I and my team use "file" for our include files and <file> for
system include files. It makes it easy to see at a glace to what a specific
include file belongs to. We also always put system include files first since
we can modify ours to understand them, but not the other way around.
Additionally, we put the "functional group" as part of the pathname in
"files". For example:
.../coolapp/main.cc:
#include "service/database.h"
#include "coolapp/ui.h"
Brian
( bcwhite@bnr.ca )
------------------------------------------------------------------------------
In theory, theory and practice are the same. In practice, they're not.
---
[ 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. ]
Author: girod@dshp01.trs.ntc.nokia.com (Marc Girod)
Date: 1995/11/23 Raw View
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?
--
+---------------------------------------------------------------------------+
| Marc Girod - Nokia Telecommunications Phone: +358-0-511 27703 |
| Kilo RD 4 - P.O. Box 12 Fax: +358-0-511 27432 |
| SF-02611 Espoo 61 - Finland Internet: marc.girod@ntc.nokia.com |
| X.400: C=FI, A=Elisa, P=Nokia Telecom, SUR=Girod, GIV=Marc |
+---------------------------------------------------------------------------+
[ 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. ]
Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1995/11/24 Raw View
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. ]
Author: hf@colibri.de (Harald Fuchs)
Date: 1995/11/24 Raw View
girod@dshp01.trs.ntc.nokia.com (Marc Girod) writes:
> 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.
Allowing two different #include forms means allowing two different
lookup rules. Since the exact meaning is (as you correctly note)
outside of the language, I guess this is a quality of implementation
issue: if ``#include "..."'' does not give you "your header" or if
``#include <...>'' does not give you "the system header" (whatever
that might mean), bug your vendor.
[ 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. ]