Re: About #include statements and other related questions
On Dec 8, 12:49 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 7 Dec, 19:49, Vicent Giner-Bosch <vgi...@gmail.com> wrote:
(2) Which is the difference between #include <something>,
used for standard library includes
#include <iostream>
#include <something.h>,
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.
#include "something.h"?
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
<windows.h> or <unistd.h>. It's also not unusual for some third
party software to be considered "system" in some applications.
(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
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
<something.h> doesn't find it.
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?
In the Windows world, it's usual to have an installer do
everything automatically.
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 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.
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!)
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.
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.
More generally, this should be part of telling the compiler that
this library is part of the "system".
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.
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:-).)
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).
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.
--
James Kanze