I need a talking to about libraries. How come some you need to download (for example the Boost libraries) where others you don't (for example iostream)? What does the .h mean at the end (e.g. windows.h) and is it required? Is there an easy way to tell which library needs to be included for the function (for example you can't guess by name that unistd.h is required for getcwd())
Well your compiler vendor will give you a standard implementation. Potentially everything else doesn't come standard, so you will have to install GUI APIs that you want to use, sound libraries, bignum libraries, game engines, whatever.I need a talking to about libraries. How come some you need to download (for example the Boost libraries) where others you don't (for example iostream)?
.h is the extension for C header files. C++ has a couple of its own - .hpp and .hxx for example. I've always considered the extension required for organizational purposes. The compiler knows what to do with files with that extension. You could always try and see what your IDE or compiler tolerates. Read your user manual.What does the .h mean at the end (e.g. windows.h) and is it required?
Not really. You need to use a reference online or offline that you can search by function name. It's an occupational hazard - you just have to commit some brain space to this part of it.Is there an easy way to tell which library needs to be included for the function (for example you can't guess by name that unistd.h is required for getcwd())
- Some libraries are TOO common,so the standard of the language has decided to include them to the language.The others that you have to download are included too common,so they are not included.However new standards come up, so some new libraries may be included or removed from the standard.
- .h is what you use in c.In c all libraries have a .h termination of name.It is because you include only the prototypes,not the whole code.As for instance,you would do if you would create your own small library.Now where the .h comes from i do not know (some googling maybe be useful )
- Guessing and coding must be two completely irrelevant things in my opinion.So do not guess,but when you have a function with name "someFunction" just search it in the google by adding the word ref(for reference) and the language in which you write(optional).
e.g. i do not remember where memcpy is included,then i would search for "memcpy ref c" or"memcpy ref c++" depending on the language that i write.When you get to ref page everything is very easy to understand
PS-gaining experience you are going to remember most functions where they are included and not searching the whole time on net
The extension of the header file, source files are only required by convention for files you create. If you create an include file you can name it anything and use any extension you want, even leave the extension off. The compiler looks for the exact file name you put into the <> or " " it doesn't care what name or extension you use. However, using a different extension would probably be considered a bad practice by most programmers. Your source files like wise can also have any or no extension, the compiler, IDE can be told to treat these files as C/C++ source files, no matter what there extension. It is also quite common to see a header file with the same name as a source file, and the extensions help you determine the purpose of these files.What does the .h mean at the end (e.g. windows.h) and is it required?
The best way of finding what header file is required for different functions is to look at the documentation for the function. For example getcwd(). Searching for the function name of standard functions will usually yield decent results. This function while not a standard C/C++ function is a standard POSIX function.Is there an easy way to tell which library needs to be included for the function (for example you can't guess by name that unistd.h is required for getcwd())
Jim
Last edited by jimblumberg; 08-27-2012 at 05:12 PM.
If .h only contains the prototypes how come including them will allow you to use the functions, as if their bodies are already defined? Take for instance windows.h, if it only contains the prototype how come you can call getcwd()?Originally Posted by std10093
- Some libraries are TOO common,so the standard of the language has decided to include them to the language.The others that you have to download are included too common,so they are not included.However new standards come up, so some new libraries may be included or removed from the standard.
- .h is what you use in c.In c all libraries have a .h termination of name.It is because you include only the prototypes,not the whole code.As for instance,you would do if you would create your own small library.Now where the .h comes from i do not know (some googling maybe be useful )
- Guessing and coding must be two completely irrelevant things in my opinion.So do not guess,but when you have a function with name "someFunction" just search it in the google by adding the word ref(for reference) and the language in which you write(optional).
e.g. i do not remember where memcpy is included,then i would search for "memcpy ref c" or"memcpy ref c++" depending on the language that i write.When you get to ref page everything is very easy to understand
PS-gaining experience you are going to remember most functions where they are included and not searching the whole time on net
Because your compiler automatically links against several "standard" libraries. The getcwd() function is in one of the "standard" libraries so you don't need to add a library to your project. But if you use functions that are not part of what your compiler considers as a standard library you will need to add the library that contains the implementations into your project.If .h only contains the prototypes how come including them will allow you to use the functions, as if their bodies are already defined? Take for instance windows.h, if it only contains the prototype how come you can call getcwd()?
Also there are some libraries that are "header only" libraries, meaning that both the prototypes and the implementations are in the header file. This happens most often with C++ template libraries.
Jim
Last edited by jimblumberg; 08-30-2012 at 11:43 PM.
If you're on a UNIX system you can say "man memcpy" (or "man 3 memcpy" if there is a command with the same name) and that will pull up a manual page that mentions which header file the function is in. Once you've used them for a while you get a sense of which headers you should be including for what purposes. You can also access man pages online, as std10093 mentioned, usually just by googling the name of the function or "man memcpy".
Basically there are two parts to any library: header files, which have function prototypes; and actual library files, which contain the code and which you must link to. For example, if I use pthreads, then I might include <pthread.h> and start using the functions; but until I actually linked with libpthread.a (as it's called on Linux; Windows might say pthread.lib) I'd have linker errors because the linker wouldn't know where to find the code for pthread_create(), pthread_attr_init(), etc. There's actually another layer of complexity. Some libraries are linked statically, which means the code is included in your executable, and some are linked dynamically: this means the library is loaded at run-time (more efficient if many programs use the same library). On Windows, DLL files are dynamic libraries, and on Linux I can see pthread being loaded by my hello world program compiled with pthreads:
DLLs perform the same function on Windows.Code:$ ldd hello linux-vdso.so.1 => (0x00007fff20fad000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb39fe38000) /lib64/ld-linux-x86-64.so.2 (0x00007fb3a01e1000) $ ldd hellopthread linux-vdso.so.1 => (0x00007fff831ff000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f207f118000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f207ed91000) /lib64/ld-linux-x86-64.so.2 (0x00007f207f356000) $
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
