When to use #include <> and #include " "

[Tuckers]

My question is, if I have created my own library which lives in its own
install directory, to refer to its header file is it better to use

#include "MyLibrary.h"

or

#include <MyLibrary.h>

Assume that this library will be used by other groups. I think the answer
should be use the "<>" notation but I would be interested why.

cheers

Tuckers

 

[ben]

<> is reserved for the standard library and some system libraries. so you
may use ""

ben

 

[Ron Natalie]

<> is reserved for the standard library and some system libraries. so you
may use ""

<> assures that if you give it the name of a standard header, you get
that for sure. Otherwise the behavior of #include is implementation
defined as to what the interpretation of the quoted string is (and
which set of delimeters you used).

 

[Rapscallion]

<> is reserved for the standard library and some system libraries. so you
may use ""

Nonsense. The path in which the header is looked up is different,
nothing else (see a good C++ book for details).

R.C.

 

[Jaspreet]

#include "MyLibrary.h"
Generally reserved for headers which are a part of the system package

#include <MyLibrary.h>

Usually for user defined headers.

I am not sure but the compiler first starts looking in /usr/include or
the INCLUDE path for headers within <> and then searches in the current
directory if it does not find the header there.

For headers within "", the compiler first starts looking in the current
directory and then moves to the INCLUDE directory path.

Let me know if I am wrong.

 

[Rapscallion]

<> assures that if you give it the name of a standard header, you get
that for sure.

Where did you get this from???

Otherwise the behavior of #include is implementation
defined as to what the interpretation of the quoted string is (and
which set of delimeters you used).

incomprehensible.

 

[Howard]

Generally reserved for headers which are a part of the system package

Usually for user defined headers.

Those are backwards.

I am not sure but the compiler first starts looking in /usr/include or
the INCLUDE path for headers within <> and then searches in the current
directory if it does not find the header there.

For headers within "", the compiler first starts looking in the current
directory and then moves to the INCLUDE directory path.

Let me know if I am wrong.

You are wrong.

The <> notation directs the compiler to look in whatever it defines as the
"system directories" (which is dependent on the OS, and possibly on settings
the user can make to the OS, such as path variables). (Note that there IS
NO /usr/include on a Windows system.) In any case, provided that the
compiler has been "properly" installed (i.e., its libraries haven't been
manually fooled with), this notation specifies the "system" files, meaning
all the standard headers, plus any that have been installed in that same
path, plus any that might be included by the user having added to the system
path information.

The "" notation is generally used for "user" files, and can be just about
anything, depending on the compiler implementation. Generally, they're the
files that are somehow specified as part of the "project", or for which the
project has been told where to look for its source files (via "project
settings"), or files in the project's home directory.

So... use <> for the standard headers. Use "" for your own files. For
third-party files, it will depend on where they've been installed and how
your system+compiler+project are set up currently. You could try using <>
and see if that works. If not, use "". If it still doesn't work, look up
how to specify where to find user files in your compiler's documentation.

-Howard

 

[Alf P. Steinbach]

* Tuckers:

My question is, if I have created my own library which lives in its own
install directory, to refer to its header file is it better to use

#include "MyLibrary.h"

or

#include <MyLibrary.h>

Assume that this library will be used by other groups. I think the answer
should be use the "<>" notation but I would be interested why.

The standard only specifies that "" may do some _additional_ searching.

In practice that additional searching includes the directory of the file
containing the #include directive.

Just for completeness: it's also valid to use a macro for the filename.

 

[Krishanu Debnath]

so you



Where did you get this from???

From Standard, Sec 16.2. It says ...

-2- A preprocessing directive of the form

# include <h-char-sequence> new-line

searches a sequence of implementation-defined places for a header
identified uniquely by the specified sequence between the < and >
delimiters.

So if your compiler implementation cannot find a standard header file,
included in the above manner, it is very likely that you are using a
broken compiler.

incomprehensible.

What?

Krishanu

 

[jdibling]

Be careful when you #include within a header file.

Suppose you have a header file foo.h, which reads like this:

[foo.h]

#include <bar.h>

class FooFighter
{
static Bar* CreateFoo(); // Bar is declared in bar.h
};

------------------------------

foo.h and bar.h are in the directory c:\foostuff. Let's say that
c:\foostuff is not in the system directory.

Your client code is like this:

[main.cpp]

#include "foo.h"

int main()
{
return 0;
}
-------------------

....and main.cpp is in c:\mygizmo.

If you compile this code, you'll get an error becasue - even though
foo.h and bar.h are in the same directory - the compiler won't be able
to find bar.h becasue it was #include'd using the angle brackets.

 

[davidrubin]

Using quotes is artificial considering that you can specified -I rules
(or whatever your compiler supports) to search in whatever directories
you want for header files. Hence you can use these rules, and include
everything using <>. /david

 

[John Dibling]

What do you mean by "artificial?"

As far as I can tell, you have devised a way to defeat the intention of
the standard - e.g., the intention to allow #include "" and #include <>
to behave differently.

Is this correct, and if so, what benefit do you gain?

</dib>

 

[davidrubin]

The only benefit of having I can see in having both "" and <> is to
replace an existing header file in the standard include path with a
local version. You can do this just as easily with -I rules. Otherwise,
you are just making an unnecessary distinction between what is "local"
and what is installed in the system include path. For example, if you
decide to move your local llibrary include files into the system path
(e.g., /usr/local/include), the logical separation implied by including
with quotations is no longer accurate.

Furthermore, it is much easier to perform source-code analysis and to
generate code programatically if you stick to one include template and
change only the build meta-data.

 

[Rapscallion]

From Standard, Sec 16.2. It says ...

-2- A preprocessing directive of the form

# include <h-char-sequence> new-line

searches a sequence of implementation-defined places for a header
identified uniquely by the specified sequence between the < and >
delimiters.

You left out importent parts.
# include <h-char-sequence>
"How the places are specified or the header identified is
implementation-defined."

#include "q-char-sequence"
"The named source file is searched for in an implementation-defined
manner."

In both cases almost nothing is defined by the C++ Standard. Most
things are left "implementation-defined".

So if your compiler implementation cannot find a standard header file,
included in the above manner, it is very likely that you are using a
broken compiler.

Not at all. At least not according to the C++ Standard.

R.C.

 

[Ron Natalie]

"Jaspreet" <[email protected]> wrote in message

You are wrong.

The <> notation directs the compiler to look in whatever it defines as the
"system directories"

Actually, you're also wrong. It's entirely implementation defined. The
only thing know for a fact is that "" will also search do the <>
as a last resort.

 

[Ron Natalie]

so you



Where did you get this from???

16.2 defines how <> and "" work. It pretty much pegs them as
implementation defined except that "" will revert to <> as
a minimum.

17.4.3.2 pretty much indicates that <standard_header_name> will
give you the standard_header_name if such a file is provided
by the implementation.

incomprehensible.

The standard says it's implementation defined. With small exception
16.2 says what you get with #include (even to the point of not requiring
headers being in files) is implementation defined.

While your (and most popular) implementations may do this by a simple
search path manipulation, that's not necessarily the case.

 

[E. Robert Tisdale]

My question is, "If I have created my own library
which lives in its own install directory,
to refer to its header file, is it better to use

#include "MyLibrary.h"

or

#include <MyLibrary.h>

Assume that this library will be used by other groups.
I think the answer should be use the "<>" notation
Correct.

but I would be interested why.

Originally,

#include "MyLibrary.h"

meant that the C preprocessor should search for
the MyLibrary.h header file in the same directory
as the header or source file that included it and

#include <MyLibrary.h>

meant that the C preprocessor should search
include directories specified by the implementation
and, perhaps, by C preprocessor options.

Standardization required some distance
between the C computer programming language
and implicit dependence upon any underlying UNIX file system.
The behavior is officially "implementation dependent".

Some C and C++ programmers insist that the <> notation
is to be reserved only for implementation defined header files.
This is *not* so.
It can and *should* be used for *any* compile-time library
which is not specific to any particular application
that may be installed as part of the general development system.
For example:

grep include /usr/include/X11/Xlib.h | grep X

#include <X11/X.h>
#include <X11/Xfuncproto.h>
#include <X11/Xosdefs.h>

The <> notation is used even though X11 is *not* part
of the implementation (gcc) or even part of the operating system.

My compiler (and, certainly, your compiler) will allow you
to add directories to the search path for these header files
but those options are implementation dependent
and beyond the scope of this newsgroup.

 

[Old Wolf]

so

Nonsense. The path in which the header is looked up is different,
nothing else (see a good C++ book for details).

Sorry, but you're wrong. Firstly, there is not necessarily a
'path' to be 'looked up': one popular compiler I use has no
files called <iostream>, <string> , etc., although you can
#include those names and get the expected results.
Secondly, the C++ standard is a more accurate reference
than a C++ book.

 

[ThosRTanner]

My question is, if I have created my own library which lives in its own
install directory, to refer to its header file is it better to use

#include "MyLibrary.h"

or

#include <MyLibrary.h>

Assume that this library will be used by other groups. I think the answer
should be use the "<>" notation but I would be interested why.

cheers

Tuckers

The standard defines that
a) #include <xxx> will get xxx from somewhere implementation defined
b) #include "xxx" will get xxx from somewhere implementation defined,
but if it can't find it there, it will try wherever it looks for files
specified in <>

SO, if you want to be safe, you always use "xxx" for your own files and
<xxx> for "system" files. I've known (different) compilers where
a) Files in <> were looked up inside the compiler. Therefore <xxx>
would never work for user files. Files using "" used what was specified
with -I compiler switches.
b) -I was used to extend where "" looked and -J was used to extend
where <> looked.
c) "" looks in the directory the containing file was found and -I
extends where <> looks (more or less unix standard)
d) at least 3 other strange variants.
All of these are conformant, and the only way you can be really safe is
to use <> for compiler / system supplied headers, and "" for user
headers, and make sure you specify the paths to the user headers fairly
explicitly.