Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C++ include statements

Reply
Thread Tools

C++ include statements

 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      08-15-2005
* Jacob:
> Is there still a difference on the two forms
> of includes:
>
> #include "some/file"
>
> and
>
> #include <some/file>
>
> I always use the latter and see no rational
> reason to distinguish between "system" headers
> and "enterprise" headers.


The former allows the compiler to search in addition places, which in
practice means the directory of the file doing the #include.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
 
 
 
Jacob
Guest
Posts: n/a
 
      08-15-2005
Is there still a difference on the two forms
of includes:

#include "some/file"

and

#include <some/file>

I always use the latter and see no rational
reason to distinguish between "system" headers
and "enterprise" headers.

Thanks!
 
Reply With Quote
 
 
 
 
Gianni Mariani
Guest
Posts: n/a
 
      08-15-2005
Jacob wrote:
> Is there still a difference on the two forms
> of includes:
>
> #include "some/file"
>
> and
>
> #include <some/file>
>
> I always use the latter and see no rational
> reason to distinguish between "system" headers
> and "enterprise" headers.


On some compilers (gcc) automatically generated header dependantcies are
only done with the "" style includes. Hence, any header file you expect
to be in your source tree should use "" style includes and anything
outside your source tree should use <> style includes.

"" style includes will first be searched for in the same directory as
the file being included.
 
Reply With Quote
 
benben
Guest
Posts: n/a
 
      08-15-2005
> The former allows the compiler to search in addition places, which in
> practice means the directory of the file doing the #include.


In addition to what Alf had said, a standard header to be #included with <>
need not be a file at all, although I haven't seen a real life example of
so.

ben


 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      08-15-2005
Jacob wrote:

>
> I'd suggest always using the <> syntax so that you don't
> accidently find include files through mysterious (and
> possibly compiler/platform dependent) ways.
>


You've obviously been hit over the head with the "non-portable" club too
many times. There's nothing wrong with compiler/platform dependent ways
of finding include files. If you port your code to another platform you
deal with it. In practice, unless you're deliberately displacing headers
you won't run into problems. Indeed, your original example of #include
<some/file> will cause you more problems than the include paths themselves.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      08-15-2005
* Jacob:
> Alf P. Steinbach wrote:
>
> > The former allows the compiler to search in addition places, which in
> > practice means the directory of the file doing the #include.

>
> But if you depend on this fact you probably has a flaw
> in your development environment.


No.

It's been this way, with good reason, since K&R C in 1972 or thereabouts.


> I'd suggest always using the <> syntax so that you don't
> accidently find include files through mysterious (and
> possibly compiler/platform dependent) ways.


First, it's not a problem.

Second, if it were a problem, the proposed solution would not be a solution.


> Suggestions?


Forget all you've "learned" in your current workplace.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
Pete Becker
Guest
Posts: n/a
 
      08-15-2005
Jacob wrote:
>
> I'd suggest always using the <> syntax so that you don't
> accidently find include files through mysterious (and
> possibly compiler/platform dependent) ways.
>


Forgot to mention: the compiler's lookup rules are mysterious only if
you don't look 'em up. Unfortunately, there seems to be a trend among
programmers today to program by guesses rather than knowledge.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
 
Reply With Quote
 
Jacob
Guest
Posts: n/a
 
      08-15-2005
Alf P. Steinbach wrote:

> The former allows the compiler to search in addition places, which in
> practice means the directory of the file doing the #include.


But if you depend on this fact you probably has a flaw
in your development environment.

I'd suggest always using the <> syntax so that you don't
accidently find include files through mysterious (and
possibly compiler/platform dependent) ways.

Suggestions?

 
Reply With Quote
 
Default User
Guest
Posts: n/a
 
      08-15-2005
Jacob wrote:

> Alf P. Steinbach wrote:
>
> > The former allows the compiler to search in addition places, which
> > in practice means the directory of the file doing the #include.

>
> But if you depend on this fact you probably has a flaw
> in your development environment.
>
> I'd suggest always using the <> syntax so that you don't
> accidently find include files through mysterious (and
> possibly compiler/platform dependent) ways.




Our common coding standard mandates that user-defined headers be
enclosed in "" and system (not-necessarily standard) ones in <>.

That make sense to me, because that way the maintainer knows whether
the header should be in the code tree or if it's found somewhere else.



Brian
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
if statements and case statements questions John Crichton Ruby 6 07-12-2010 06:17 PM
/* #include <someyhing.h> */ => include it or do not include it?That is the question .... Andreas Bogenberger C Programming 3 02-22-2008 10:53 AM
Prepare Statements VS Statements Vince Java 12 01-21-2008 01:18 PM
component statements within architecture statements Neil Zanella VHDL 8 10-20-2006 09:05 AM
if statements with or w/o else statements Harry George Python 6 02-23-2004 06:48 PM



Advertisments