About #include statements and other related questions

[Vicent Giner-Bosch]

Hello.

I am used to "old" programming languages, like FORTRAN, BASIC ("Goto
10"), and so on --or maybe I should say "old" programming techniques,
where the whole program was in one file, and so on.

And now I am working with Visual C++ 6.0, on Windows XP. I understand
that #include sentences are used for "including" other program files
into the current "program" (project), so that the functions they
contain can be also "called" by my main program or routine. OK.

But, what I don't understand is the following:

(1) Which is the difference between a ".cpp" file and a ".h" file? Why
is it more frequent including ".h" files than ".cpp" ones?

(2) Which is the difference between #include <something>, #include
<something.h>, #include "something.h"? Are they interchangeable?

(3) I have ".cpp" example files that contain #include
<something.h> and I have to change it by #include "something.h"
in order to make it work -- I mean, if I try to compile the ".cpp"
file, I get an error when I have #include <something.h> ("No such
file or directory"), and I don't get any error or warning when I
change it by #include "something.h". It always happens the same,
with every project (even with examples, as I said), no matter which
files I am including. Is that an expected behavior?? Is it maybe
something related with MS Visual C++ options or settings??

(4) The biggest problem/question here:

I am working with the GNU Scientific Library (GSL), specifically with
GSL 1.11 "prepared" for Windows by David Geldreich (http://
david.geldreich.free.fr/dev.html). I downloaded and unzipped the
"binaries for Windows" package. I copied the "gsl" folder (the one
which is in the "include" folder, and that contains lots of ".h"
files) in the same directory where my main ".cpp" file is.

In my main ".cpp" file I have #include "gsl/gsl_cdf.h", because
#include <gsl/gsl_cdf.h> didn't work for me, as I said at (3).

I compile the main file (Ctrl+F7), and everything is OK.

Then, I try to build the main file (F7), called "OPCA_01.cpp", and I
get this error:

""" Linking...
OPCA_01.obj : error LNK2001: unresolved external symbol
_gsl_cdf_ugaussian_P
Debug/OPCA_01.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe. """

In my program, I call a function called "gsl_cdf_ugaussian_P", which
is defined in the file "gsl_cdf.h", which is in the "gsl" folder.

I don't understand why I get that estrange error. I didn't typewrite
"_gsl_cdf_ugaussian_P" in any moment.

So, can you help me to understand what am I doing wrong???

Thank you in advance for your help.

 

[Richard]

[Please do not mail me a copy of your followup]

Vicent Giner-Bosch <[email protected]> spake the secret code

And now I am working with Visual C++ 6.0, on Windows XP. [...]

Get rid of VC6 and download Visual C++ Express 2008.

 

[Tim Slattery]

(1) Which is the difference between a ".cpp" file and a ".h" file? Why
is it more frequent including ".h" files than ".cpp" ones?

A *.cpp file is expected to contain C++ code. It will probably include
several *.h files, which are expected to include declarations only.

(2) Which is the difference between #include <something>, #include
<something.h>, #include "something.h"? Are they interchangeable?

With the brackets, the preprocessor looks in the system include
libraries for the specified file. With quotes, it looks first in the
directory of the file doing the including resides, then in the system
libraries. So no, they are not interchangeable.

*.h files date from C, and the extension generally means that they
were written with that language in mind. Includes written for C++
generally don't have the suffix/

(3) I have ".cpp" example files that contain #include
<something.h> and I have to change it by #include "something.h"
in order to make it work --

See above. What's gong on is that something.h resides in the same
directory as the *.cpp file including it. When you use the brackets,
that directory is not searched.

Then, I try to build the main file (F7), called "OPCA_01.cpp", and I
get this error:

""" Linking...
OPCA_01.obj : error LNK2001: unresolved external symbol
_gsl_cdf_ugaussian_P
Debug/OPCA_01.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe. """

In my program, I call a function called "gsl_cdf_ugaussian_P", which
is defined in the file "gsl_cdf.h", which is in the "gsl" folder.

I don't understand why I get that estrange error. I didn't typewrite
"_gsl_cdf_ugaussian_P" in any moment.

It's probably in one of those include files. And there should be a
*.obj file in the package, or maybe a *.lib file, that contains what
the linker is looking for.

 

[Vicent Giner-Bosch]

[Please do not mail me a copy of your followup]

Vicent Giner-Bosch <[email protected]> spake the secret code

And now I am working with Visual C++ 6.0, on Windows XP. [...]

Get rid of VC6 and download Visual C++ Express 2008.

Richard,

Do you mean that VC6 is THE problem, or is it just a suggestion??

 

[Richard]

[Please do not mail me a copy of your followup]

As far as the C/C++ compiler is concerned, each translation unit is a
pile of text. As long as each translation unit declares external
identifiers consistently, the linker will have the proper references
to bind all the translation units together and resolve the references
between them.

The include mechanism just provides for a way to provide the text of
the declarations of external entities without having to repeat them in
every translation unit.

A translation unit is typically named '*.c' or '*.cpp', but these are
just conventions -- the compiler doesn't care at all about the name of
the file it is asked to compile. It could just as easily be called
'main.rumplestilskin' as it is called 'main.cpp'.

The same is true for header files; the .h naming convention is merely
a convention when it comes to your own header files. Standard header
files have standard names. For C, these standard headers all end in
..h; for C++ specific standard headers they have no suffix and the C++
standard defines a mechanism whereby standard C headers can be
included without a suffix. This has implications for the identifiers
declared in those headers; without a suffix most identifiers will be
declared in namespace std, with a suffix most identifiers will be
declared in the global namespace. (Preprocessor symbols don't exist
within a namespace, regardless of where they come from.)

For instance, if you include <cctype>, then you get std::isalpha(), but
if you include <ctype.h> then you get ::isalpha(). For C standard
headers included without the suffix, you also prepend 'c' to the
header name. C++ headers would be things like <string> (which gets
you the std::string /class/), not <string.h> (which gets you C string
/functions/).

Tim Slattery <[email protected]> spake the secret code

With the brackets, the preprocessor looks in the system include
libraries for the specified file. With quotes, it looks first in the
directory of the file doing the including resides, then in the system
libraries. So no, they are not interchangeable.

I'm not sure what the standard requires for search paths when you use
<> vs. "". However, every compiler I've ever used allows you to
define such search paths to such an extent that I've not had any
problems using either one.

 

[Richard]

[Please do not mail me a copy of your followup]

Vicent Giner-Bosch <[email protected]> spake the secret code

[Please do not mail me a copy of your followup]

Vicent Giner-Bosch <[email protected]> spake the secret code

And now I am working with Visual C++ 6.0, on Windows XP. [...]

Get rid of VC6 and download Visual C++ Express 2008.

Richard,

Do you mean that VC6 is THE problem, or is it just a suggestion??

Both.

VC6 is a 10 year old buggy compiler that has weak standards
conformance. The standard library implementation is buggy.

VC++ Express 2008 is a modern compiler with much better standards
conformance. The standard library implementation is much improved in
quality.

 

[Rolf Magnus]

(1) Which is the difference between a ".cpp" file and a ".h" file? Why
is it more frequent including ".h" files than ".cpp" ones?

It's rather the other way round. If a file is supposed to be included, you
give it a name that ends in .h (other names are also used sometimes, like
e.g. .hpp or .hxx). It's basically a convention.

(2) Which is the difference between #include <something>, #include
<something.h>, #include "something.h"? Are they interchangeable?

Include with <> and "" use different search paths to find the header file.
When including a system header or library header, use <>. When including a
header from your own project, use "".

There is not really a difference between #include <something> and #include
<something.h> except that the first includes a header named something, the
other includes one named something.h. But since they include different
headers, they are not interchangeable.

(3) I have ".cpp" example files that contain #include
<something.h> and I have to change it by #include "something.h"
in order to make it work -- I mean, if I try to compile the ".cpp"
file, I get an error when I have #include <something.h> ("No such
file or directory"), and I don't get any error or warning when I
change it by #include "something.h". It always happens the same,
with every project (even with examples, as I said), no matter which
files I am including. Is that an expected behavior?? Is it maybe
something related with MS Visual C++ options or settings??

There are compiler options that can be used to add directories to the header
search path. If you add the current directory (".") then you can probably

(4) The biggest problem/question here:

I am working with the GNU Scientific Library (GSL), specifically with
GSL 1.11 "prepared" for Windows by David Geldreich (http://
david.geldreich.free.fr/dev.html). I downloaded and unzipped the
"binaries for Windows" package. I copied the "gsl" folder (the one
which is in the "include" folder, and that contains lots of ".h"
files) in the same directory where my main ".cpp" file is.

Is there no way to correctly "install" it?

In my main ".cpp" file I have #include "gsl/gsl_cdf.h", because
#include <gsl/gsl_cdf.h> didn't work for me, as I said at (3).

The best option would be to put all the stuff that belongs to the library
into a subdirectory of your project, then add its header directory to the
compiler's search path.

I compile the main file (Ctrl+F7), and everything is OK.

Then, I try to build the main file (F7), called "OPCA_01.cpp", and I
get this error:

""" Linking...
OPCA_01.obj : error LNK2001: unresolved external symbol
_gsl_cdf_ugaussian_P
Debug/OPCA_01.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe. """

In my program, I call a function called "gsl_cdf_ugaussian_P", which
is defined in the file "gsl_cdf.h", which is in the "gsl" folder.

My guess is that it's not defined in that file, but rather only declared.

I don't understand why I get that estrange error. I didn't typewrite
"_gsl_cdf_ugaussian_P" in any moment.

It's a "mangled" name - a name that the compiler uses internally to refer to
that function.

So, can you help me to understand what am I doing wrong???

You probably need to link to the library. The header file only tells the
compiler which functions there are and how you have to call them (argument
list, return value, ...), but it doesn't contain the actual function code.
That code is put in a library which you have to link your program to.

 

[James Kanze]

It's rather the other way round. If a file is supposed to be
included, you give it a name that ends in .h (other names are
also used sometimes, like e.g. .hpp or .hxx). It's basically a
convention.

More to the point, all such endings are conventions. In
practice, compilers will usually treat .c as C code; .cpp, .cxx
or .cc as C++, and various other endings as other things. (E.g.
..f for Fortran, .a or .ada for Ada, .p for Pascal, etc. Many
compilers will also pass on any ending they don't know about to
the linker.)

With regards to include, all of the compilers I know simply use
the string in the include directive as the name of the file,
with no particular mapping, so you can use literally anything
(and I've seen quite a few variations). The usual convention is
..h for C headers and .hpp, .hxx or .hh for C++ headers, but a
lot of people seem to like confusing the two. And not a few
places will introduce special endings for special types of
headers: .tcc for template implementation code (to separate it
from the header), .inl for inline function definitions, etc. (I
also use .lhh for local headers, which won't be exported, but I
think that's a personal convention. I've also used .ihh for
inline function definitions---so *.hh matches exported C++
headers, and *.*hh matches all C++ headers.)

Include with <> and "" use different search paths to find the
header file. When including a system header or library
header, use <>. When including a header from your own project,
use "".

There is one difference required by the standard: where the
compiler looks for <...> must be a subset of where it looks for
"...". Typically, the compiler will look for "..." in the
directory where the file doing the include is found, then treat
it as <...>. (Formally, the standard doesn't require <...> to
even be a file, but in practice, I've only heard of one compiler
where this was the case.)

There is not really a difference between #include <something>
and #include <something.h> except that the first includes a
header named something, the other includes one named
something.h. But since they include different headers, they
are not interchangeable.

There are compiler options that can be used to add directories
to the header search path. If you add the current directory
(".") then you can probably also use <> to include your own
headers, but the preferred way is to use "" for those.

Is there no way to correctly "install" it?

The best option would be to put all the stuff that belongs to
the library into a subdirectory of your project, then add its
header directory to the compiler's search path.

Actually, I'd make the library a separate project, and import
it. (Not sure how to do that under Visual Studios, but from the
command line, you can import something by specifying the include
path for the headers -- -I or /I -- and the filename with the
library.)

My guess is that it's not defined in that file, but rather
only declared.

And of course, that he hasn't specified the library when
linking. Or that the headers are pure C (without a conditional
``extern "C"''), and he included them as is, without wrapping
them in an ``extern "C"'' declaration. So the compiler
processed the function declarations as if they were C++, but
when it compiled the function definition in the .c file, it
processed it as C.

It's a "mangled" name - a name that the compiler uses
internally to refer to that function.

Or is it? I would expect the mangled name to be more
complicated than that, with at least some sequences that aren't
legal in user C++ (like "__" or an initial "_X", where X is any
capital letter).

You probably need to link to the library. The header file only
tells the compiler which functions there are and how you have
to call them (argument list, return value, ...), but it
doesn't contain the actual function code. That code is put in
a library which you have to link your program to.

Was the library delivered precompiled, or does he have to
compile it as well?

 

[Nick Keighley]

And now I am working with Visual C++ 6.0, on Windows XP. [...]
Get rid of VC6 and download Visual C++ Express 2008.

Do you mean that VC6 is THE problem, or is it just a suggestion??

Both.

VC6 is a 10 year old buggy compiler that has weak standards
conformance.  The standard library implementation is buggy.

VC++ Express 2008 is a modern compiler with much better standards
conformance.  The standard library implementation is much improved in
quality.

yes, but I doubt VC6 is the casue of his problem. He needs to
understand what #include is all about. And about linking to libraries.

 

[Nick Keighley]

*.h files date from C, and the extension generally means that they
were written with that language in mind. Includes written for C++
generally don't have the suffix/

this is far from being universally true. I've seen a lot of C++
headers with .h extensions.

 

[Nick Keighley]

I am used to "old" programming languages, like FORTRAN, BASIC ("Goto
10"),

are there still BASICs (or FORTRANs) that do that!! That's so last
millenium!

and so on --or maybe I should say "old" programming techniques,
where the whole program was in one file, and so on.

And now I am working with Visual C++ 6.0, on Windows XP. I understand
that #include sentences are used for "including" other program files
into the current "program" (project), so that the functions they
contain can be also "called" by my main program or routine. OK.

the function "declarations" they contain, actually. Simplifying
outrageaously, the cpp files contain the code (the function
"definition") and the .h (header) files the function prototype (the
"declaration").

int fred(int); // declaration

int fred (int n)
{ return n + 1; } // definition

This is slightly complicated by "inline" definitions that /can/ appear
in header files. These either have the keyword "inline" or appear
inside class definitions.

But, what I don't understand is the following:

(1) Which is the difference between a ".cpp" file and a ".h" file?

see above

Why is it more frequent including ".h" files than ".cpp" ones?

never include a .cpp. When you understand when to break this rule you
won't be asking questions like this. ("hardly ever" is the answer).

(2) Which is the difference between   #include <something>,

used for standard library includes

  #include <something.h>,  

used for legacy C library includes

#include <limits.h>

in fact avoid these and use the equivalent C++ includes

#include "something.h"?

  Are they interchangeable?

not really.

(3) I have ".cpp" example files that contain   #include
<something.h>

what is "something" is it a standard C library header or not? If it is
then your compiler installation is broken and you need to fix it. If
not then, yes, the "" is better. You can tell VS where to search for
include files. Try the help or an MS newsgroup.

and I have to change it by   #include "something.h"
in order to make it work -- I mean, if I try to compile the ".cpp"
file, I get an error when I have   #include <something.h>   ("No such
file or directory"), and I don't get any error or warning when I
change it by   #include "something.h".   It always happens the same,
with every project (even with examples, as I said),

I suspect your compiler is misconfigured some how

no matter which
files I am including. Is that an expected behavior?? Is it maybe
something related with MS Visual C++ options or settings??

could well be

(4) The biggest problem/question here:

I am working with the GNU Scientific Library (GSL), specifically with
GSL 1.11 "prepared" for Windows by David Geldreich (http://
david.geldreich.free.fr/dev.html). I downloaded and unzipped the
"binaries for Windows" package.

were their installation instructions?

I copied the "gsl" folder (the one
which is in the "include" folder, and that contains lots of ".h"
files) in the same directory where my main ".cpp" file is.

that sounds wrong.

In my main ".cpp" file I have  #include "gsl/gsl_cdf.h",   because
#include <gsl/gsl_cdf.h>  didn't work for me, as I said at (3).

MS ng

I compile the main file (Ctrl+F7), and everything is OK.
hurrah!

Then, I try to build the main file (F7), called "OPCA_01.cpp", and I
get this error:

""" Linking...
OPCA_01.obj : error LNK2001: unresolved external symbol
_gsl_cdf_ugaussian_P
Debug/OPCA_01.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe. """

you need to tell it where to find the library file. This may be
an .obj or an .so (i think!)

In my program, I call a function called "gsl_cdf_ugaussian_P", which
is defined in the file "gsl_cdf.h",

no it isn't. Its *declared* in gsl_cdf.h, this is a promise to your
compiler that you will provide the code (definition) for this function
before the final code is linked together. You broke your promise. You
need to tell VS where to look for the object code (this is where ever
you put the rest of the GSL stuff). See MS ng for details.

which is in the "gsl" folder.

I don't understand why I get that estrange error. I didn't typewrite
"_gsl_cdf_ugaussian_P" in any moment.

the C++ buggers up (the technical term is "mangles") the names for
esoteric technical reasons too painful to go into right now.

So, can you help me to understand what am I doing wrong???

1. read a good book that explains about #include and its various form
and just what should and shouldn't go in a header file. (you'll have
to ask someelse to find out what is the current recomendation for such
a book).

2. read the VS help or ask on an MS ng how to configure VS to find the
include files and the libraries.

 

[RJ]

There is a completely OOP Basic supported by OpenQM, which is a multivalue
file manager based system modeled after the old Pick Systems. Fortran and
Cobol are still very heavily used. It is probably easier for a Fortran or
Cobol programmer to find a decent job than for someone who reads this group.
BobJ

 

[Tim Slattery]

this is far from being universally true. I've seen a lot of C++
headers with .h extensions.

No argument here. But that's the intention, isn't it?

 

[James Kanze]

As far as the C/C++ compiler is concerned, each translation
unit is a pile of text. As long as each translation unit
declares external identifiers consistently, the linker will
have the proper references to bind all the translation units
together and resolve the references between them.

The include mechanism just provides for a way to provide the
text of the declarations of external entities without having
to repeat them in every translation unit.

A translation unit is typically named '*.c' or '*.cpp', but
these are just conventions -- the compiler doesn't care at all
about the name of the file it is asked to compile. It could
just as easily be called 'main.rumplestilskin' as it is called
'main.cpp'.

That's only partially true. In fact, no one today ever invokes
a compiler, we invoke a compiler driver (which is usually what
is meant by the compiler), which invokes a compiler for each
source file, and the linker after that. And this compiler
driver does look at the name of the file, in order to determine
which language to use. Typically, .c will cause it to invoke
the C compiler, .cpp, .cxx or .cc the C++ and maybe .f the
Fortran compiler, .p the Pascal compiler, etc. Most of the
drivers I've seen will pass any suffix they don't know directly
to the linker, so "compiling" main.rumplestilskin without any
special options will generally cause the linker to complain hat
main.rumplestilskin doesn't have a legal object or library file
format.

The same is true for header files; the .h naming convention is
merely a convention when it comes to your own header files.
Standard header files have standard names. For C, these
standard headers all end in .h; for C++ specific standard
headers they have no suffix and the C++ standard defines a
mechanism whereby standard C headers can be included without a
suffix. This has implications for the identifiers declared in
those headers; without a suffix most identifiers will be
declared in namespace std, with a suffix most identifiers will
be declared in the global namespace. (Preprocessor symbols
don't exist within a namespace, regardless of where they come
from.)

Just a nit (because as far as I know, no compiler really uses
this freedom), but the standard speaks of <...> as including a
header, not a file; the text might not even reside on the file
system. And the standard also allows mapping the filenames in
an implementation dependent way: today, this simply means that
on some systems, "Toto.h" and "toto.h" will refer to the same
file, and on others not, but in the past, I've used systems
where "longname1.h" and "longname2.h" referred to the same file,
and in theory at least, many other mappings are legal. I seem
to recall having heard that systems that use some character
other than '/' as a directory separator will map '/' to their
directory separator. (I'm not thinking of Windows here, where
both '/' and '\' are legal directory separators as far as the
system is concerned.)

For instance, if you include <cctype>, then you get
std::isalpha(), but if you include <ctype.h> then you get
::isalpha(). For C standard headers included without the
suffix, you also prepend 'c' to the header name. C++ headers
would be things like <string> (which gets you the std::string
/class/), not <string.h> (which gets you C string
/functions/).

Tim Slattery <[email protected]> spake the secret code
<[email protected]> thusly:

I'm not sure what the standard requires for search paths when
you use <> vs. "". However, every compiler I've ever used
allows you to define such search paths to such an extent that
I've not had any problems using either one.

The standard says that the search paths are implementation
defined, and that when it searches for a "...", if it doesn't
find it, it rewrites the directive as <...> and tries that.

In theory, you can think of all sorts of strange solutions which
are still fully conformant, but in practice, every compiler I
know uses the directory of the including file for "...", then
your -I or /I options (for both) and various system places.

 

[James Kanze]

used for standard library includes

#include <iostream>

used for legacy C library includes

#include <limits.h>

in fact avoid these and use the equivalent C++ includes

#include <climits>

That's arguable. If you're using a C header, and C
functionality, why hide the fact, and pretend you're getting
something you're not.

anyone elses includes. Some libraries break these rules and
use the <> form.

The <> form is traditionally used for "system" headers: I'd use
it not only for the standard headers, but also for things like

what is "something" is it a standard C library header or not?
If it is then your compiler installation is broken and you
need to fix it. If not then, yes, the "" is better. You can
tell VS where to search for include files. Try the help or an
MS newsgroup.

I suspect your compiler is misconfigured some how

As you said earlier, it depends on whether the header in
question is part of the system, or part of the application. If
it's part of the application, it's perfectly normal that

could well be

were their installation instructions?

In the Windows world, it's usual to have an installer do
everything automatically.

that sounds wrong.

MS ng

I think the problem is more general. His library is probably
meant to be considered more or less an extention to the system
(so any examples in the documentation do contain
<gsl/gsl_cdf.h>), but he's "installed" them as part of his
application. Regardless of the system, the general steps for
using a third party library are similar: install it somewhere
(generally where other users can also access it, but never
directly as part of your application), then tell your compiler
(via makefiles or project options) to consider it as part of the
system.

you need to tell it where to find the library file. This may be
an .obj or an .so (i think!)

If he's under Windows, it will be a .lib. There may also be a
..dll, but in that case, you also have a stub .lib which you link
against.

Given his explinations above, it's also possible that the
library was provided in source form, and that he has to compile
it first.

no it isn't. Its *declared* in gsl_cdf.h, this is a promise to
your compiler that you will provide the code (definition) for
this function before the final code is linked together. You
broke your promise. You need to tell VS where to look for the
object code (this is where ever you put the rest of the GSL
stuff). See MS ng for details.

More generally, this should be part of telling the compiler that
this library is part of the "system".

the C++ buggers up (the technical term is "mangles") the names
for esoteric technical reasons too painful to go into right
now.

This is *not* a mangling from VC++. It looks more as if it is a
C function name (declared in an ``extern "C"'' block). While he
may not have invoked it, it's quite possible that he invoked a
macro which did. (This is a C library, after all.)

1. read a good book that explains about #include and its
various form and just what should and shouldn't go in a header
file. (you'll have to ask someelse to find out what is the
current recomendation for such a book).

I'm not aware of one. Lakos has some fairly good points, but is
quite dated.

2. read the VS help or ask on an MS ng how to configure VS to
find the include files and the libraries.

The library should include information on how to install it for
the compilers it supports. If the library doesn't support VC++,
then he's probably got a bit of work in front of him, since it's
likely that it uses some Unix particularisms, comes with a
makefile that only works under Unix, etc.

 

[Default User]

No argument here. But that's the intention, isn't it?

No. Standard headers (aside from the old C headers) have no extension.
It's not at all common for user-generated headers to be without. Some
people use a .hpp extension. Most I have seen stick with good old .h.




Brian

 

[Nick Keighley]

No argument here. But that's the intention, isn't it?

what? Whose intention? I literally have access to thousands of .h
files that declare classes. Does the standard suggest you shouldn't
use .h files for C++?

 

[Nick Keighley]

please don't top post

There is a completely OOP Basic supported by OpenQM, which is a multivalue
file manager based system modeled after the old Pick Systems. Fortran and
Cobol are still very heavily used. It is probably easier for a Fortran or
Cobol programmer to find a decent job than for someone who reads this group.

and are there still BASICs and FORTRANs that use line numbers and
gotos? Did you actually read what I wrote?

<snip>

 

[Nick Keighley]

That's arguable.  If you're using a C header, and C
functionality, why hide the fact, and pretend you're getting
something you're not.

there are also subtle differences in the meaning

The <> form is traditionally used for "system" headers: I'd use
it not only for the standard headers, but also for things like
<windows.h> or <unistd.h>.  It's also not unusual for some third
party software to be considered "system" in some applications.

I'm not keen on it though.

(4) The biggest problem/question here:
I am working with the GNU Scientific Library [...] I
downloaded and unzipped the "binaries for Windows" package.

were [there] installation instructions?

In the Windows world, it's usual to have an installer do
everything automatically.

but there's a fair amount of "teckie" stuff that just gives you a raw
zip file and expects you do it all yourself.

I think the problem is more general.  His library is probably
meant to be considered more or less an extention to the system
(so any examples in the documentation do contain
<gsl/gsl_cdf.h>), but he's "installed" them as part of his
application.

well I agree he probably shouldn't have "installed" them as part of
his application; but I'm not sure when a library stops being "a system
extension" and starts being "application specific". If a home brew
protocol is only used in a particular application is it a system

 Regardless of the system, the general steps for
using a third party library are similar: install it somewhere
(generally where other users can also access it, but never
directly as part of your application), then tell your compiler
(via makefiles or project options) to consider it as part of the
system.

yes. That's why I directed him to an MS ng that presumably could tell
him about the project options.

If he's under Windows, it will be a .lib.  There may also be a
.dll, but in that case, you also have a stub .lib which you link
against.

Given his explinations above, it's also possible that the
library was provided in source form, and that he has to compile
it first.

he mentioned the word "binary" so I guessed he had an object file.

1. read a good book that explains about #include and its
various form and just what should and shouldn't go in a header
file. (you'll have to ask some[one] else to find out what is the
current recomendation for such a book).

I'm not aware of one.  

"The C++ programming Language" 3e section 9.2.1

"Accelerated C++" p66

Hell, even K&R will describe the basics. I just didn't know what the
current recomendation is for a good beginners book.

Lakos has some fairly good points, but is quite dated.

bit heavy for the current poster

The library should include information on how to install it for
the compilers it supports.

and people /should/ be nice to each other but we live in an imperfect
world.

 If the library doesn't support VC++,
then he's probably got a bit of work in front of him, since it's
likely that it uses some Unix particularisms, comes with a
makefile that only works under Unix, etc.

fun fun fun!

 

[Joe Smith]

Try to use the rules I suggest if you can.

The convention is nearly universal that standard headers and system headers
(such as kernel headers, or POSIX headers) are included with <>, never with
"". Headers that are part of the local project use "", never <>.

There is some gray area for libraries. If they are installed in the central
location for the system, then it is generally normal to use <>. That is why
you see <> used with the boost headers most of the time. If they are local
to a project or group of projects, "" is pretty common.

Generally the convention is <> unless the header is local to the project or
a project group in which case "" is used. This has been the standard
convention for both C and C++ since before either was standardized. I'd
advise against deviating from this standard unless there is a really good
reason to do so. This is what people expect.