About #include statements and other related questions

Discussion in 'C++' started by Vicent Giner-Bosch, Dec 7, 2009.

  1. 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.
     
    Vicent Giner-Bosch, Dec 7, 2009
    #1
    1. Advertising

  2. Vicent Giner-Bosch

    Richard Guest

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

    Vicent Giner-Bosch <> spake the secret code
    <> thusly:

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


    Get rid of VC6 and download Visual C++ Express 2008.
    --
    "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
    <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

    Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
     
    Richard, Dec 7, 2009
    #2
    1. Advertising

  3. Vicent Giner-Bosch

    Tim Slattery Guest

    Vicent Giner-Bosch <> wrote:

    >(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.

    --
    Tim Slattery

    http://members.cox.net/slatteryt
     
    Tim Slattery, Dec 7, 2009
    #3
  4. On 7 dic, 21:04, (Richard) wrote:
    > [Please do not mail me a copy of your followup]
    >
    > Vicent Giner-Bosch <> spake the secret code
    > <> thusly:
    >
    > >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??
     
    Vicent Giner-Bosch, Dec 7, 2009
    #4
  5. Vicent Giner-Bosch

    Richard Guest

    [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 <> spake the secret code
    <> thusly:

    >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.
    --
    "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
    <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

    Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
     
    Richard, Dec 7, 2009
    #5
  6. Vicent Giner-Bosch

    Richard Guest

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

    Vicent Giner-Bosch <> spake the secret code
    <> thusly:

    >On 7 dic, 21:04, (Richard) wrote:
    >> [Please do not mail me a copy of your followup]
    >>
    >> Vicent Giner-Bosch <> spake the secret code
    >> <> thusly:
    >>
    >> >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.
    --
    "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
    <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

    Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
     
    Richard, Dec 7, 2009
    #6
  7. Vicent Giner-Bosch

    Rolf Magnus Guest

    Vicent Giner-Bosch wrote:

    > (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
    also use <> to include your own headers, but the preferred way is to use ""
    for those.

    > (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.
     
    Rolf Magnus, Dec 8, 2009
    #7
  8. Vicent Giner-Bosch

    James Kanze Guest

    On Dec 8, 5:52 am, Rolf Magnus <> wrote:
    > Vicent Giner-Bosch wrote:
    > > (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.


    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.)

    > > (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 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.


    > > (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 also use <> to include your own
    > headers, but the preferred way is to use "" for those.


    > > (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.


    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.)

    > > 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.


    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.

    > > 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.


    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).

    > > 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.


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

    --
    James Kanze
     
    James Kanze, Dec 8, 2009
    #8
  9. On 7 Dec, 22:27, (Richard) wrote:
    > Vicent Giner-Bosch <> spake the secret code
    > <> thusly:
    > >On 7 dic, 21:04, (Richard) wrote:
    > >> Vicent Giner-Bosch <> spake the secret code
    > >> <> thusly:



    > >> >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, Dec 8, 2009
    #9
  10. On 7 Dec, 21:14, Tim Slattery <> wrote:

    > *.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, Dec 8, 2009
    #10
  11. On 7 Dec, 19:49, Vicent Giner-Bosch <> wrote:

    > 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 <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>

    >#include "something.h"?


    anyone elses includes. Soem libraries break these rules and use the <>
    form. Try to use the rules I suggest if you can.

    >  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.


    > Thank you in advance for your help.



    --
    Nick Keighley
     
    Nick Keighley, Dec 8, 2009
    #11
  12. Vicent Giner-Bosch

    RJ Guest

    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

    "Nick Keighley" <> wrote in message
    news:...
    > On 7 Dec, 19:49, Vicent Giner-Bosch <> wrote:
    >
    >> 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 <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>
    >
    >>#include "something.h"?

    >
    > anyone elses includes. Soem libraries break these rules and use the <>
    > form. Try to use the rules I suggest if you can.
    >
    >> 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.
    >
    >
    >> Thank you in advance for your help.

    >
    >
    > --
    > Nick Keighley
    >
     
    RJ, Dec 8, 2009
    #12
  13. Vicent Giner-Bosch

    Tim Slattery Guest

    Nick Keighley <> wrote:

    >On 7 Dec, 21:14, Tim Slattery <> wrote:
    >
    >> *.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.


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

    --
    Tim Slattery

    http://members.cox.net/slatteryt
     
    Tim Slattery, Dec 8, 2009
    #13
  14. Vicent Giner-Bosch

    James Kanze Guest

    On Dec 7, 10:24 pm, (Richard) wrote:
    > 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 <> spake the secret code
    > <> thusly:


    > >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.


    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
     
    James Kanze, Dec 8, 2009
    #14
  15. Vicent Giner-Bosch

    James Kanze Guest

    On Dec 8, 12:49 pm, Nick Keighley <>
    wrote:
    > On 7 Dec, 19:49, Vicent Giner-Bosch <> 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
     
    James Kanze, Dec 8, 2009
    #15
  16. Vicent Giner-Bosch

    Default User Guest

    Tim Slattery wrote:

    > Nick Keighley <> wrote:
    >
    > >On 7 Dec, 21:14, Tim Slattery <> wrote:
    > >
    > >> *.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.

    >
    > 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
     
    Default User, Dec 8, 2009
    #16
  17. On 8 Dec, 14:25, Tim Slattery <> wrote:
    > NickKeighley<> wrote:
    > >On 7 Dec, 21:14, Tim Slattery <> wrote:


    > >> *.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.

    >
    > 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, Dec 10, 2009
    #17
  18. please don't top post

    On 8 Dec, 13:50, "RJ" <> wrote:
    > "NickKeighley" <> wrote in message
    > news:...
    > > On 7 Dec, 19:49, Vicent Giner-Bosch <> wrote:



    > >> 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!

    >
    > 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, Dec 10, 2009
    #18
  19. On 8 Dec, 15:24, James Kanze <> wrote:
    > On Dec 8, 12:49 pm, NickKeighley<>
    > wrote
    > > On 7 Dec, 19:49, Vicent Giner-Bosch <> wrote:


    <snip>

    > > >   #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.


    there are also subtle differences in the meaning


    > > >#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.


    I'm not keen on it though.

    <snip>

    > > > (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 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.


    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
    extension or not? I don't like adding <> includes willy-nilly.


    > 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.


    > > > 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.


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

    <snip>

    > > > 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 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


    > > 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.


    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!


    --
    Nick Keighley

    "There are some ideas so wrong that only a very intelligent person
    could believe in them." -- George Orwell
     
    Nick Keighley, Dec 10, 2009
    #19
  20. Vicent Giner-Bosch

    Joe Smith Guest

    "Nick Keighley" <>:
    >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.
     
    Joe Smith, Dec 11, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Neil Zanella
    Replies:
    8
    Views:
    1,196
    mfmehdi
    Oct 20, 2006
  2. Harry George
    Replies:
    6
    Views:
    384
    Bart Nessux
    Feb 23, 2004
  3. Vince
    Replies:
    12
    Views:
    751
    Martin Gregorie
    Jan 21, 2008
  4. Andreas Bogenberger
    Replies:
    3
    Views:
    934
    Andreas Bogenberger
    Feb 22, 2008
  5. John Crichton
    Replies:
    6
    Views:
    267
    John Crichton
    Jul 12, 2010
Loading...

Share This Page