conventions for #include delimiter (quotes versus angle brackets)
Andrew
#include <myheader.h>
and
#include "myheader.h"
My preference is for the latter. I only use angle brackets for headers
that are standard for C++. But that's just my preference, I usually
don't argue the point. What are the pros and cons please?
Regards,
Andrew Marlow
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Neil Butterworth
> There doesn't seem much to choose between:
>
> #include <myheader.h>
>
> and
>
> #include "myheader.h"
>
> My preference is for the latter. I only use angle brackets for headers
> that are standard for C++. But that's just my preference, I usually
> don't argue the point. What are the pros and cons please?
The C++ Standard says that exactly what these directives do is
implementation-defined. However, it also says that the quoted version
will do what the angle-bracketed version does if the quoted versions
implementation defined action fails.
This is not too helpful, but basically means you can normally use
either. Personally, I use the angle-bracket version for the standard
headers (like you) and also for system headers like windows.h or
sys/whatever.h, and use the quoted version for my own and third party
headers.
Neil Butterworth
ChrisH
> There doesn't seem much to choose between:
>
> #include <myheader.h>
>
> and
>
> #include "myheader.h"
>
> My preference is for the latter. I only use angle brackets for headers
> that are standard for C++. But that's just my preference, I usually
> don't argue the point. What are the pros and cons please?
{ edits: quoted sig & banner removed. don't quote signatures or the banner. -mod }
we just had a problem where the code used #import "header" for both
local and standard headers
It broke the build when a new component was added who's name shadowed
a standard library name.
Based on this and past issue with header including I prefer to use
"myheader" and <standard header>
Cheers
Chris
Bo Persson
> There doesn't seem much to choose between:
>
> #include <myheader.h>
>
> and
>
> #include "myheader.h"
>
> My preference is for the latter. I only use angle brackets for
> headers that are standard for C++. But that's just my preference, I
> usually don't argue the point. What are the pros and cons please?
>
This is all implementation-defined. All the standard says is that the
< > form searches some places for the header to include. The " " form
seaches some places for the header and, if not found there, also
seaches the same places as the < > would do.
As the standard doesn't require directories or other ways to keep your
files, or how the header name is mapped to a possible file system
name, it cannot be more specific.
Bo Persson
ThosRTanner
> There doesn't seem much to choose between:
>
> #include <myheader.h>
>
> and
>
> #include "myheader.h"
>
> My preference is for the latter. I only use angle brackets for headers
> that are standard for C++. But that's just my preference, I usually
> don't argue the point. What are the pros and cons please?
>
compilers where
1) The standard headers don't actually exist except inside the
compiler
2) The standard header include path is controlled by different
switches to the other include path. (i.e. -I doesn't affect #include
<>)
Both of these were from (different) compliant compilers. And both mean
that
#include <myheader.h>
fails to compile.
All the standard says is something along the lines of
#include <xxx> finds xxx somewhere implementation specific, A say.
#include "yyy" finds yyy somewhere else implementation specific. If it
can't find it there, it'll try to find it in A.
Louis Lavery
> On Nov 25, 2:19 pm, Andrew <marlow.and...@googlemail.com> wrote:
>> There doesn't seem much to choose between:
>>
>> #include <myheader.h>
>>
>> and
>>
>> #include "myheader.h"
>>
>> My preference is for the latter. I only use angle brackets for headers
>> that are standard for C++. But that's just my preference, I usually
>> don't argue the point. What are the pros and cons please?
>>
> I infinitely prefer the latter. This is because I have come across
> compilers where
>
> 1) The standard headers don't actually exist except inside the
> compiler
> 2) The standard header include path is controlled by different
> switches to the other include path. (i.e. -I doesn't affect #include
> <>)
>
> Both of these were from (different) compliant compilers. And both mean
> that
>
> #include <myheader.h>
>
> fails to compile.
>
> All the standard says is something along the lines of
>
> #include <xxx> finds xxx somewhere implementation specific, A say.
> #include "yyy" finds yyy somewhere else implementation specific. If it
> can't find it there, it'll try to find it in A.
I use
#include <myLib/pathTo/myheader.h>
and use an environment variable to point the compiler at
directory myLibVersionNumber that contains direcory myLib.
This seems to force the compiler (vc8) to look only in that
directory (do other compilers do the same?).
The reason for doing that is that using just this
#include "myheader.h"
vc8 goes on a grand tour, should it not find myheader.h
in the local directory, and can find another myheader.h
in some other directory.
Louis.
ThosRTanner
wrote:
>
> I use
>
> #include <myLib/pathTo/myheader.h>
>
> and use an environment variable to point the compiler at
> directory myLibVersionNumber that contains direcory myLib.
> This seems to force the compiler (vc8) to look only in that
> directory (do other compilers do the same?).
#include "myLib/pathTo/myHeader.h" should work just as well (or in
some cases, better)
>
> The reason for doing that is that using just this
>
> #include "myheader.h"
>
> vc8 goes on a grand tour, should it not find myheader.h
> in the local directory, and can find another myheader.h
> in some other directory.
If it can't find <myLib/pathTo/myHeader.h> it is still likely to go on
a grand tour . It is just rather less likely to find multiple
instances of the file, because people tend not to have directory trees
with matching names. But it can still happen.
If you have this structure
MyLibA/Wibble/Wibble.h
and
MyLibB/Wibble/Wibble.h
and do
CC -I MyLibA -I MylLibB
then #include "Wibble/Wibble.h" won't necessarily get the file you
want.
Having multiple directories in your -I list is a good way of slowing
down your compilations. Not to mention quite a good way of getting
surprising behaviour of you have multiple header files with the same
name..
Andrew
> On Nov 27, 1:27 pm, Louis Lavery <Lo...@LaverREMOVE.demon.co.uk>
> wrote:
> > The reason for doing that is that using just this
>
> > #include "myheader.h"
>
> > vc8 goes on a grand tour,
> If it can't find <myLib/pathTo/myHeader.h> it is still likely to go on
> a grand tour .
> Having multiple directories in your -I list is a good way of slowing
> down your compilations. Not to mention quite a good way of getting
> surprising behaviour of you have multiple header files with the same
> name..
It seems like several people have the same preference as me but that
it is largely a matter of preference. I was hoping for some sound
principle of practise for why one would be preferred to the other. I
am working on a code base where there is a massive mixture of styles
for include, often within the same translation unit. Obviously
consistency would be a good thing, but not if it is going to spark a
preferences war (on my project, not here in this ng).
So far the strongest argument I have seen is that some compilers make
<header.h> an internal thing so "header.h" has to be used for headers
that don't come with the compiler. But I must admit I have never come
across a compiler that behaved that way. I realise this territory is
all "implementation-defined" but in practise nearly all compilers
implement headers as file system objects (in my experience).
Regards,
Andrew M.
Louis Lavery
> On Nov 25, 2:19 pm, Andrew <marlow.and...@googlemail.com> wrote:
>> There doesn't seem much to choose between:
>>
>> #include <myheader.h>
>>
>> and
>>
>> #include "myheader.h"
>>
>> My preference is for the latter. I only use angle brackets for headers
>> that are standard for C++. But that's just my preference, I usually
>> don't argue the point. What are the pros and cons please?
>>
> I infinitely prefer the latter. This is because I have come across
> compilers where
>
> 1) The standard headers don't actually exist except inside the
> compiler
> 2) The standard header include path is controlled by different
> switches to the other include path. (i.e. -I doesn't affect #include
> <>)
>
> Both of these were from (different) compliant compilers. And both mean
> that
>
> #include <myheader.h>
>
> fails to compile.
Would something like
#include <fullPath/myheader.h>
fail to compile?
Louis.
Louis Lavery
The last time I looked, Boost seemed to use a mix of <> and "", and
I remember there was a discussion regards the matter at one time, so
even the experts seem confused/undecided about it.
Louis.
Philip
is what I standardized on also. In general, when in doubt about
anything, look at how boost does it :-)
Nick Hounsome
Several places I have worked have coding standards mandating one or
the other (usualy <> I think) on the basis that the compilers used
only gauranteed to look in the -I directories first if you use that
format (obviously this is not C++ standards stuff).
In practice it was always unnecessary because all standard headers are
lowercase and all ours were PascalCase so a clash with an
implementation header was never going to happen.
IMHO the most useful/common convention is to use "" for stuff created
for the project and <> for everthything else.
Perhaps the powers that be should create a new form #include <<xxx>>
that is gauranteed to ONLY look in "standard" places and
#include ""xxx"" to ONLY look in user specified places (-I dirs) or
perhaps more generally #include <<scope::name>> where scope can be
"std" or any user defined string and the compiler has different
mappings for different scopes - This would allows different libraries
to more easily coexist ( Then have options such as -Iscope1::/proj1
etc ).
Francis Glassborow
> Boost library uses #include <> notation (almost) exclusively, so this
> is what I standardized on also. In general, when in doubt about
> anything, look at how boost does it :-)
>
And I think that Boost does it that way because it is about as close to
an implementation as you can get without being the Standard.
This makes it even more important that I keep my own header files away
from possible clashes.
Francis Glassborow
>
> It seems like several people have the same preference as me but that
> it is largely a matter of preference. I was hoping for some sound
> principle of practise for why one would be preferred to the other. I
> am working on a code base where there is a massive mixture of styles
> for include, often within the same translation unit. Obviously
> consistency would be a good thing, but not if it is going to spark a
> preferences war (on my project, not here in this ng).
>
> So far the strongest argument I have seen is that some compilers make
> <header.h> an internal thing so "header.h" has to be used for headers
> that don't come with the compiler. But I must admit I have never come
> across a compiler that behaved that way. I realise this territory is
> all "implementation-defined" but in practise nearly all compilers
> implement headers as file system objects (in my experience).
>
> Regards,
>
> Andrew M.
>
Yes but I have come across a C compiler that did not have files for
standard headers. It is harder for C++ because of the extensive use of
templates.
But there is another issue, that of mapping file names to the file
system. Let me give you an example.
On the Archimedes machine (from Acorn) the file system did not support
extensions (such as .c etc.) so the compiler had to map things like x.h
into a file called x in a folder called h. I.e. the file extension
became a folder. Now such mappings could be (an for all I know, were)
different for user header files and for implementation header files.
That difference might well cause problems if the user started grabbing
system/implementation file names.
I have always rigidly adhered to using angle brackets for system and
implementation headers and quotes for my own. That provides a clear
separation between the two. It means that my headers are always on a
path that will not be searched for system/implementation headers and so
I never have to worry about name clashes.
I suspect that this is about on a par with conventions for naming macros
(every competent, experienced C or C++ programmer knows the irritation
when some third party causes a name collision by using lower case in
macro names.
Philip
<francis.glassbo...@btinternet.com> wrote:
> And I think that Boost does it that way because it is about as close to
> an implementation as you can get without being the Standard.
How does that help with the issues you mention, like compilers not
storing system headers as files? Boost would suffer from these issues
just like any other project.
> This makes it even more important that I keep my own header files away
> from possible clashes.
But you don't. Standard doesn't guaranty any more protection from
clashes when using both #include notations.
> ... It means that my headers are always on a path that
> will not be searched for system/implementation headers ...
No it doesn't. A (standard conformant) compiler could search the exact
same folders whether "" or <> notation is used.
Andrew
> > This makes it even more important that I keep my own header files away
> > from possible clashes.
>
> But you don't. Standard doesn't guaranty any more protection from
> clashes when using both #include notations.
>
> > ... It means that my headers are always on a path that
> > will not be searched for system/implementation headers ...
>
> No it doesn't. A (standard conformant) compiler could search the exact
> same folders whether "" or <> notation is used.
Indeed. That is why I said (right at the start) that technically there
doesn't seem to be much difference between them - people seem to be
coming down on the use of double quotes to document whether or not the
header is considered to be a project header (as opposed to a standard
header). But it looks like this is merely a convention.
Tony Delroy
> There doesn't seem much to choose between:
> #include <myheader.h>
> and
> #include "myheader.h"
While the Standard is vague, in my experience most compilers seeing
#include "myheader.h" will search the directory of the file performing
the include, so it's a convenient way to indicate a same-directory(-
relative) file.
For that reason, I use #include "..." when I'm including some
localised dependency. For example: in app_guts.cc, #include
"app_guts.h" (where 'guts' indicates some of app's implementation,
split off to keep file sizes smaller and functionality grouped, only
ever included by other files in the same directory that are also part
of the implementation of app).
If myheader.h is a public top-level interface for "mylib", then I have
the app #include <mylib/myheader.h> (less clash-prone) or <myheader.h>
(less work if mylib is renamed, or the functionality moves between
libraries). Should myheader.h's logical content be split across
physical files, then it might #include "subdir/myheader_guts.h".
Quotes help here: when mylib/mylib.test.cc wants to #include
"mylib.h", it hangs together to allow the test harness to compile
without need of -I command-line arguments specifying the horrible "-
I.", or needing to know/generate/patch-in the "installation"
directory.
If I want the build process to have to specify the location of the
header via -I command line switch, or I'm including a system header, I
indicate that the filesystem paths (and functionality) are independent/
decoupled and build-time configurable, and that I don't need or want
local paths implicitly searched, using #include <myheader.h>.
Cheers,
Tony
Louis Lavery
A little too complicated for me.
I stick to #include <fullPath/myHeader.hpp> throughout.
It has the advantage that I can tell at a glance what file is to be
included, whereas #include "myHeader.hpp" requires I know where
the file that's doing the include is (even then it's not clear where
the compiler will look). Also if I move the file that's doing the
#include "myHeader.hpp", or "myHeader.hpp itself, I'm in trouble.
Louis.
ThosRTanner
>
> So far the strongest argument I have seen is that some compilers make
> <header.h> an internal thing so "header.h" has to be used for headers
> that don't come with the compiler. But I must admit I have never come
> across a compiler that behaved that way. I realise this territory is
> all "implementation-defined" but in practise nearly all compilers
> implement headers as file system objects (in my experience).
>
different places for <> and "" includes, and using -I controls the ""
search path, whereas a different switch is used for the <> search
path.
I'm just pointing out that in my experience using "" for user files
and <> for system supplied files has been a safer way of proceeding.
Andrew
> On Nov 25, 11:19 pm, Andrew <marlow.and...@googlemail.com> wrote:
>
> > There doesn't seem much to choose between:
> > #include <myheader.h>
> > and
> > #include "myheader.h"
>
> While the Standard is vague, in my experience most compilers seeing
> #include "myheader.h" will search the directory of the file performing
> the include, so it's a convenient way to indicate a same-directory(-
> relative) file.
Yes. Among the many reasons I have seen for #include "myheader.h" one
reason is to avoid saying -I. on the compiler command line.
> For that reason, I use #include "..." when I'm including some
> localised dependency.
I never thought of that. When I first saw your post I didn't like it
because that it because I was so fixed on "" being used to document
whether or not the header is a standard header. But thinking of java
import for a minute, java programmers do not mind seeing imports from
here there and everywhere and no-one seems to worry about employing
any convention to distinguish between standard imports and project
imports. Related imports are grouped but that's all.
So maybe the use of double quotes as a documentation aid is not that
powerful/useful after all. I am still not sure. In java it is alot
easier to navigate around classes and between packages, both system
and project. In C++ this is alot harder since it does not have
packages. But it is not impossible. The eclipse plugin for C++ builds
up the information that helps you navigate around.
So it looks like my original main reason may not be that strong.
People have quoted compiler cases where it matters that a non-standard
header is not included via angle brackets but that does sound a bit
weird to me so I don't think that reason is very strong either. I
remember the K&C C compiler for the BBC Micro, similar to the Acorn
Risk machine that Francis mentioned, had the weird way of mapping
filename to the name employed in the #include. But this was due to a
weirdness in the filesystem due to the way it handled drive letters.
It did not really alter the way that #include worked, you could still
employ angle brackets or double quotes.
-Andrew M.
Louis Lavery
> On 2 Dec, 13:08, Philip <philip.stan...@gmail.com> wrote:
>>> This makes it even more important that I keep my own header files away
>>> from possible clashes.
>> But you don't. Standard doesn't guaranty any more protection from
>> clashes when using both #include notations.
>>
>>> ... It means that my headers are always on a path that
>>> will not be searched for system/implementation headers ...
>> No it doesn't. A (standard conformant) compiler could search the exact
>> same folders whether "" or <> notation is used.
>
> Indeed. That is why I said (right at the start) that technically there
> doesn't seem to be much difference between them - people seem to be
> coming down on the use of double quotes to document whether or not the
> header is considered to be a project header (as opposed to a standard
> header). But it looks like this is merely a convention.
>
The question is "Why is there more than one way to #include"?
It seems to be solely for the benefit of the compiler.
Louis.
Seungbeom Kim
>
> The question is "Why is there more than one way to #include"?
>
> It seems to be solely for the benefit of the compiler.
Isn't it good to have a way to differentiate different kinds of headers:
(1) language standard (<limits>, <stddef.h>)
(2) system standard (<unistd.h>, <sys/types.h>)
(3) system library (<boost/shared_ptr.hpp>, <curses.h>)
(4) project ("config.h")
..? The distinction between adjacent categories may be a little vague,
though, and I don't have a good answer to questions that arise in cases
as a boost header including another boost header, etc.
The reality is that the distinction between <...> and "...", though
it might have been intended to serve the purpose stated above, is not
doing its job very well, and that we have to depend on conventions
and manually avoiding name clashes between the categories above.
(If I remember correctly, it's not defined even what happens when you
#include "sub/foo.h" and that file #includes "bar.h" -- whether it
means "./sub/bar.h" or "./bar.h".)
--
Seungbeom Kim
Tony Delroy
> [Re my recommendations for #include "" vs <>...]
A little too complicated for me.
Fair enough... whatever's easiest for you and your system is best by
definition. Complex approaches are only useful if the consequences of
not using them is even more complex, and that depends on many things:
size and complexity of the system you maintain, the physical build
dependencies, in-house vs external client usage etc..
> I stick to #include <fullPath/myHeader.hpp> throughout.
Literally full filesystem path (so you don't need -I)? or just from
the library name? (much more common)...
> It has the advantage that I can tell at a glance what file is to be
> included, whereas #include "myHeader.hpp" requires I know where
> the file that's doing the include is (even then it's not clear where
> the compiler will look). Also if I move the file that's doing the
> #include "myHeader.hpp", or "myHeader.hpp itself, I'm in trouble.
That's why I said the determining factor for me is whether I'm likely
to move the including and included file together... i.e. they're
coupled, one providing the necessary "guts" for the other.
Summarily:
- using the full path throughout
- when you move a single file you have to modify the "upstream"
including files but none of the moved file's includes,
- moving a library interface header with its private headers, you
update upstream clients AND private dependencies.
- using only relative paths
- when you move a single file you have to modify the "upstream"
including files AND the moved file's relative includes,
- moving a library interface header with its private headers, you
update upstream clients only.
Using a hybrid approach based on the interface vs private
implementation boundaries in the code makes sense to me, so the
necessary changes to include statements are minimised.
Cheers,
Tony
ThosRTanner
> On 3 Dec, 08:34, Tony Delroy <tony_in_da...@yahoo.co.uk> wrote:
>
> > On Nov 25, 11:19 pm, Andrew <marlow.and...@googlemail.com> wrote:
>
> > > There doesn't seem much to choose between:
> > > #include <myheader.h>
> > > and
> > > #include "myheader.h"
>
> > While the Standard is vague, in my experience most compilers seeing
> > #include "myheader.h" will search the directory of the file performing
> > the include, so it's a convenient way to indicate a same-directory(-
> > relative) file.
>
> Yes. Among the many reasons I have seen for #include "myheader.h" one
> reason is to avoid saying -I. on the compiler command line.
>
> > For that reason, I use #include "..." when I'm including some
> > localised dependency.
>
> I never thought of that. When I first saw your post I didn't like it
> because that it because I was so fixed on "" being used to document
> whether or not the header is a standard header. But thinking of java
> import for a minute, java programmers do not mind seeing imports from
> here there and everywhere and no-one seems to worry about employing
> any convention to distinguish between standard imports and project
> imports. Related imports are grouped but that's all.
At one company, we had only a few directories on the -I list. So more
or less every interface header had to be included as
#include "module/submodule/header"
or it wouldn't comiple.
Louis Lavery
> Louis Lavery wrote:
>>
>> The question is "Why is there more than one way to #include"?
>>
>> It seems to be solely for the benefit of the compiler.
>
> Isn't it good to have a way to differentiate different kinds of headers:
>
It's good to know which headers are being included, so yes, if
that's what you mean.
In order to help avoid including the wrong file I use as full a
path as I can.
> (1) language standard (<limits>, <stddef.h>)
> (2) system standard (<unistd.h>, <sys/types.h>)
> (3) system library (<boost/shared_ptr.hpp>, <curses.h>)
> (4) project ("config.h")
>
> ...? The distinction between adjacent categories may be a little vague,
> though, and I don't have a good answer to questions that arise in cases
> as a boost header including another boost header, etc.
>
> The reality is that the distinction between <...> and "...", though
> it might have been intended to serve the purpose stated above, is not
> doing its job very well, and that we have to depend on conventions
> and manually avoiding name clashes between the categories above.
> (If I remember correctly, it's not defined even what happens when you
> #include "sub/foo.h" and that file #includes "bar.h" -- whether it
> means "./sub/bar.h" or "./bar.h".)
If you write
#include "thelib/sub/foo.h"
and in foo.h you write
#include "thelib/sub/bar.h"
and point your compiler at the directory containing thelib then
you'd know the files that are actually included would lie on those paths.
Well, almost. I could happen that the compiler finds the wrong
thelib/sub/foo.h nested in some local or system directory. But
that's awfully unlikely.
Louis.
--
Louis Lavery
> On Dec 4, 2:15 am, Louis Lavery <Lo...@LaverREMOVE.demon.co.uk> wrote:
>> [Re my recommendations for #include "" vs <>...]
> A little too complicated for me.
>
> Fair enough... whatever's easiest for you and your system is best by
> definition. Complex approaches are only useful if the consequences of
> not using them is even more complex, and that depends on many things:
> size and complexity of the system you maintain, the physical build
> dependencies, in-house vs external client usage etc..
>
>> I stick to #include <fullPath/myHeader.hpp> throughout.
>
> Literally full filesystem path (so you don't need -I)? or just from
> the library name? (much more common)...
I put theLib version 1.3, say, in C:\theLib1_3 and point the compiler
at C:\theLib1_3 via an environment variable (I think that's a common
way to do things). I use VC and gcc compilers.
>
>> It has the advantage that I can tell at a glance what file is to be
>> included, whereas #include "myHeader.hpp" requires I know where
>> the file that's doing the include is (even then it's not clear where
>> the compiler will look). Also if I move the file that's doing the
>> #include "myHeader.hpp", or "myHeader.hpp itself, I'm in trouble.
>
> That's why I said the determining factor for me is whether I'm likely
> to move the including and included file together... i.e. they're
> coupled, one providing the necessary "guts" for the other.
>
> Summarily:
> - using the full path throughout
> - when you move a single file you have to modify the "upstream"
> including files but none of the moved file's includes,
Yes. And the fact you're using long paths helps with that, it
reduces to a global search and replace.
> - moving a library interface header with its private headers, you
> update upstream clients AND private dependencies.
Once a library is released, moving an public header would be
highly unlikely, I'd get shot!
> - using only relative paths
> - when you move a single file you have to modify the "upstream"
> including files AND the moved file's relative includes,
How do you find all the upstream include files?
While it seems reasonable to have to change the upstream
include file (simply because what it includes has moved),
it seems some what odd to have to change a file just
because it has moved (at least it does to me).
> - moving a library interface header with its private headers, you
> update upstream clients only.
>
> Using a hybrid approach based on the interface vs private
> implementation boundaries in the code makes sense to me, so the
> necessary changes to include statements are minimised.
As I say, I wouldn't move a public header file.
When I move private files it's usually only a few related files.
If it's any more then I do it a few at a time, and changing the
include paths is rarely a problem.
Louis.
Tony Delroy
> On 3 Dec, 08:34, Tony Delroy <tony_in_da...@yahoo.co.uk> wrote:
>
> > On Nov 25, 11:19 pm, Andrew <marlow.and...@googlemail.com> wrote:
> > For that reason, I use #include "..." when I'm including some
> > localised dependency.
>
> I never thought of that. When I first saw your post I didn't like it
> because that it because I was so fixed on "" being used to document
> whether or not the header is a standard header.
The use is similar - still an us and them thing - but the cut-off line
groups other things like boost and enterprise_lib along with system
headers.
Another point I may not have made clearly: if a library uses quoted
includes internally, then it doesn't matter whether the base directory
of that library is in the -I list. Why should the library care or
dictate how the client system has included it? If you've got a
3rd_party_libs/ directory with 50 entries, it's nice to have a single -
I/x/y/3rd_party_libs after which #include <3rd_party_libs/libABC> will
work for any of the 50 "ABC"s....
> But thinking of java
> import for a minute, java programmers do not mind seeing imports from
> here there and everywhere and no-one seems to worry about employing
> any convention to distinguish between standard imports and project
> imports. Related imports are grouped but that's all.
I wasn't suggesting treating everything equally. Using "" can still
communicate something useful, just not what you had in mind.
> So maybe the use of double quotes as a documentation aid is not that
> powerful/useful after all. I am still not sure. In java it is alot
> easier to navigate around classes and between packages, both system
> and project. In C++ this is alot harder since it does not have
> packages. But it is not impossible. The eclipse plugin for C++ builds
> up the information that helps you navigate around.
On clc++m, it's good to give a summary of the functional issues rather
than just reference some other language or tool. I don't program
Java, I don't know Java's package concept (I've noticed some attempts
to get them into C++, but never paid attention), I don't use eclipse.
But, I have been meaning to try out this new fangled completion
feature in vim 7... ;-).
Cheers,
Tony
:wq
Louis Lavery
> On Dec 4, 3:23 am, Andrew <marlow.and...@googlemail.com> wrote:
>> On 3 Dec, 08:34, Tony Delroy <tony_in_da...@yahoo.co.uk> wrote:
>>
>>> On Nov 25, 11:19 pm, Andrew <marlow.and...@googlemail.com> wrote:
>>> For that reason, I use #include "..." when I'm including some
>>> localised dependency.
>> I never thought of that. When I first saw your post I didn't like it
>> because that it because I was so fixed on "" being used to document
>> whether or not the header is a standard header.
>
> The use is similar - still an us and them thing - but the cut-off line
> groups other things like boost and enterprise_lib along with system
> headers.
>
> Another point I may not have made clearly: if a library uses quoted
> includes internally, then it doesn't matter whether the base directory
> of that library is in the -I list. Why should the library care or
> dictate how the client system has included it? If you've got a
> 3rd_party_libs/ directory with 50 entries, it's nice to have a single -
> I/x/y/3rd_party_libs after which #include <3rd_party_libs/libABC> will
> work for any of the 50 "ABC"s....
>
I'm not familiar with '-I/x/y/3rd_party_libs' but, assuming it's the
same as '-I3rd_party_libs', shouldn't that be...
"after which #include <libABC> will work for any of the 50 "ABC"s...."
....?
In which case it doesn't matter whether the lib uses "" or <>, so
long as it uses the appropriate path with the latter.
Louis.
Tony Delroy
wrote:
> Tony Delroy wrote:
> > Another point I may not have made clearly: if a library uses quoted
> > includes internally, then it doesn't matter whether the base directory
> > of that library is in the -I list. Why should the library care or
> > dictate how the client system has included it? If you've got a
> > 3rd_party_libs/ directory with 50 entries, it's nice to have a single -
> > I/x/y/3rd_party_libs after which #include <3rd_party_libs/libABC> will
> > work for any of the 50 "ABC"s....
>
> I'm not familiar with '-I/x/y/3rd_party_libs' but, assuming it's the
> same as '-I3rd_party_libs', shouldn't that be...
>
> "after which #include <libABC> will work for any of the 50 "ABC"s...."
>
> ....?
>
> In which case it doesn't matter whether the lib uses "" or <>, so
> long as it uses the appropriate path with the latter.
>
> Louis.
True. Just a warning for libABC to '#include <libABC/
other_header.h>' (in preference to '#include <other_header.h>'),
should it choose not to use '#include "other_header.h"'.
Tony
Louis Lavery
> On Dec 10, 7:54 am, Louis Lavery <Lo...@LaverREMOVE.demon.co.uk>
> wrote:
>> Tony Delroy wrote:
>>> Another point I may not have made clearly: if a library uses quoted
>>> includes internally, then it doesn't matter whether the base directory
>>> of that library is in the -I list. Why should the library care or
>>> dictate how the client system has included it? If you've got a
>>> 3rd_party_libs/ directory with 50 entries, it's nice to have a single -
>>> I/x/y/3rd_party_libs after which #include <3rd_party_libs/libABC> will
>>> work for any of the 50 "ABC"s....
>> I'm not familiar with '-I/x/y/3rd_party_libs' but, assuming it's the
>> same as '-I3rd_party_libs', shouldn't that be...
>>
>> "after which #include <libABC> will work for any of the 50 "ABC"s...."
>>
>> ....?
>>
>> In which case it doesn't matter whether the lib uses "" or <>, so
>> long as it uses the appropriate path with the latter.
>>
>> Louis.
>
> True. Just a warning for libABC to '#include <libABC/
> other_header.h>' (in preference to '#include <other_header.h>'),
> should it choose not to use '#include "other_header.h"'.
>
Thanks for the clarification.
One thing though, how do you reach across to a parallel directory?
Say a file in MyApp/subA/ needs to include a file from MyApp/subB/
Do you then resort to #include <MyApp/subB/headerFromA.h> ?
I have seen (and used) #include "../subB/headerFromA.h", but don't
do that now (in fact it's one of the reasons I switched to using
<> throughout).
But maybe it's not an issue, I mean including stuff from a parallel
directory could be viewed as a bad smell - so you just don't do it.
Louis.
Tony Delroy
wrote:
> One thing though, how do you reach across to a parallel directory?
>
> Say a file in MyApp/subA/ needs to include a file from MyApp/subB/
>
> Do you then resort to #include <MyApp/subB/headerFromA.h> ?
>
> I have seen (and used) #include "../subB/headerFromA.h",
Same here.
> but don't
> do that now (in fact it's one of the reasons I switched to using
> <> throughout).
>
> But maybe it's not an issue, I mean including stuff from a parallel
> directory could be viewed as a bad smell - so you just don't do it.
It's common enough - and perfectly proper (rule-of-thumb: if not
cyclic) - to want to use some other part of the same library, and if
that library's big enough to be split across many directories (e.g.
boost), then you're in parallel directory territory. The only way I
can imagine this tangibly impacting the choice between <> and "" is if
".." is less portable, though I've never had an issue.
Cheers,
Tony