views:

386

answers:

6

Why tuple documentation for example says to use:

#include "boost/tuple/tuple.hpp"

and not

#include <boost/tuple/tuple.hpp>

I know that it's almost not probably my code will have also boost/tuple/tuple.hpp, but using include <> states explicitly not to look in the curent directory.

So what is the reason?

+3  A: 

Afaik the reason is to differentiate between headers that belong to an application and those which are from external libraries. I can't say why they have not used this convention. It is a only a convention and not a rule.

Perhaps someone should raise this issue with the Boost maintainers?

Hassan Syed
+5  A: 

The historical meaning of <somefile> is to look in the system-standard places. With "somefile" it means look in the current directory, plus some other places.

wallyk
I got -3 last time I posted that answer, even though it's(almost) right :-*. Including your files with " " and other libraries < > looks neater too. The effect on all the compilers I have tried it with is as you describe, even if the standard says otherwise. But I doubt it's worth starting a war over.
Chris Huang-Leaver
A: 

From msdn:

Quoted form

This form instructs the preprocessor to look for include files in the same directory of the file that contains the #include statement, and then in the directories of any files that include (#include) that file. The preprocessor then searches along the path specified by the /I compiler option, then along paths specified by the INCLUDE environment variable.

Angle-bracket form

This form instructs the preprocessor to search for include files first along the path specified by the /I compiler option, then, when compiling from the command line, along the path specified by the INCLUDE environment variable.

mlsteeves
MSDN is not the C++ Standard, which makes no mention of an INCLUDE variable, or even of directories.
anon
@Neil: But in your answer you specified that it looks in an implementation defined place. So for the compiler that is documented by the msdn (presumably VS). This is specifying that implementation detail mentioned in the standard.
Martin York
True enough. I meant to say that the MSDN described behaviour is not common to all C++ implementations.
anon
A: 

Are you asking what the difference between the two styles of inclusion is, or for Boost's rationale? Since others have spoken regarding the difference, I'll just add my take on the latter issue:

I don't believe either is more correct, in general. It depends on how your project is structured with respect to its dependencies. For example, in my projects I typically include the relevant bits of Boost, et cetera, in a subdirectory of the project and thus tend to prefer the #include "" form. If you want to pick up the Boost installation from a more global location, you'd prefer the #include <> form.

Josh Petrie
+6  A: 

Using <> does not mean "don't look in the current directory" - It means look in an implementation defined place and then look somewhere else, also implementation defined. Either, both or neither of these could be the current directory. This is one of the more useless bits of the C++ standard.

anon
"This is one of the more useless bits of the C++ standard". And C. I had a practical case where src/a.c included inc/component/b.h, and file b.h includes "c.h". One compiler looked in src/ (and then the rest of the path), and another compiler looked in inc/component/ (and then the rest of the path). Took a while to sort out the make/build files for that one. We standardised on putting inc/ in the include path and a.c includes "component/b.h" and b.h include "component/c.h". But even that isn't truly portable, since the meaning of "/" isn't defined.
Steve Jessop
I suspect that the vast majority of C and C++ programmers have no clue about what #include actually does for their specific implementation(s) - I know I don't.
anon
I know exactly what it does. Works On My Machine.
Steve Jessop
+1  A: 

Use <...> for boost. This is not Your code. Unless your code is boost.

Use "...." for your header files, which you inevitably have in every C++ program. This is for the reader, not for the compiler.

Pavel Radzivilovsky
+1 for posting the answer I agree with. Phew! This is beginning to make 'Man made climate change' look like a simple, easy to agree on, trivial detail :-(
Chris Huang-Leaver