.h verses .lib
When and for what should I use a .lib file for, as opposed to a header file? I''m not sure what the actual proper use for each type of file is.
I usually just put all my functions, prototypes, and defines related to one field of the game in a header file. Should I be using a .lib? Why?
Header files contains function prototypes, constant values, class definitions, structure defintions, enumerations and the like. You really can''t get around using them.
A .lib file - there are two kinds. One for statically linking with a dll, the other for merging with the exe by the linker. Header files and lib files aren''t mutually exclusive - so your question is a bit awkward. A better file to contrast against lib files would be dlls.
The advantage of using a lib file as opposed to a dll is that with a lib file the executable code is merged directly into the exe so you have fewer files to distribute. You gain a little at start up over a dll because a dll must be loaded into the process address space - but it''s not much of a gain.
With both forms you''ve modularized the code - so each is even on that, however, if you keep the interface consistent, you can more easily change the implementations of a dll without having to go back and recompile the entire project they way you would have to if you used a lib file. Only the dll has to be recompiled.
I''m also fairly certain that resources can not be stored in a lib file - where they can be stored in a dll. I''m not completely certain about that however, as I''ve never considered trying it.
A .lib file - there are two kinds. One for statically linking with a dll, the other for merging with the exe by the linker. Header files and lib files aren''t mutually exclusive - so your question is a bit awkward. A better file to contrast against lib files would be dlls.
The advantage of using a lib file as opposed to a dll is that with a lib file the executable code is merged directly into the exe so you have fewer files to distribute. You gain a little at start up over a dll because a dll must be loaded into the process address space - but it''s not much of a gain.
With both forms you''ve modularized the code - so each is even on that, however, if you keep the interface consistent, you can more easily change the implementations of a dll without having to go back and recompile the entire project they way you would have to if you used a lib file. Only the dll has to be recompiled.
I''m also fairly certain that resources can not be stored in a lib file - where they can be stored in a dll. I''m not completely certain about that however, as I''ve never considered trying it.
"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man
LessBread pretty much covered the use of .lib. However, if you create a .lib then you need to create a .h with the function prototypes and class definitions for your .lib, so that your program knows what it''s looking for in the .lib files. I personally don''t use .lib files that often because that means you have to recompile the .lib if you change something and then recompile the original program. Where if you just have all the code in the original project with it''s own .h and .cpp files, if you change something you need only recompile the project and that''s it.
I know only that which I know, but I do not know what I know.
I know only that which I know, but I do not know what I know.
I know only that which I know, but I do not know what I know.
Let me see if I can clarify this a bit, as I dont know that your question was exactly answered.
When you build your program, a number of things happen.
First, the compiler will look in your .c or .cpp files and it will search for include files. When it finds them it will directly insert the contents of the .h files into your .cpp files at compile time.
If you are using a class, function, etc...inside of your .cpp file without the code or a prototype in that file, you'd better have it inside of the header file, or it wont compile.
Once your compiler figures that all header files have been found and included in their appropriate .cpp files, then it builds the .cpp files into object files, which have an extension of .o. At this point, if you so chose, you could link several of your .o files together and through one route or another create either a .dll file or a .lib file. Otherwise, you can just link the .o files together and create your executable.
So then, what is the difference between a .h file and a .lib/.dll file. Simple, the .h file is a human readable file that must be converted at some point into an object file. A library file on the other hand is a binary file made up of already compiled header and source files.
This means a few things to you.
1. if you're putting all of your code into your header files, then at some point, in which you decide to write a game engine or something where you must distribute your header files for others to use, all of your code will be visible and change-able.
If you however put only your function prototypes in your header files and you put all of your code into a library file, no one can mess with your code.
2. If you have code that changes very little, but use it very often, dont put it into a header file. Unless you're using pre-compiled headers, then every time you compile your software you MAY be recompiling your header files as well(not necessarily). On the other hand, if you put your code into a library file, then when you get ready to build your software, the smaller header files with just the prototypes is compiled with your software, saving time, while the rest of the already compiled code is linked in at the end.
Here's my opinion. Only put structures, classes, defines and prototypes into header files. Put all code into .cpp files, and when capable, compile it into a library for easier use.
As to whether or not you should use a static or dynamic library, that depends on whether you want to distribute a larger file, or more files. Also, if you use static libraries, you're loading the entire contents of the library into memory...more or less. With dynamic, you can choose which content to load and which not to.
phew...there's my 2..er..3 cents.
Best Regards,
Jeromy "Maverick" Walsh
------------------------
"The question isn't how far, the question is do you possess the constitution, the depth of faith, to go as far as is needed?" -Boondock Saints
[edited by - jwalsh on June 12, 2002 11:06:00 PM]
When you build your program, a number of things happen.
First, the compiler will look in your .c or .cpp files and it will search for include files. When it finds them it will directly insert the contents of the .h files into your .cpp files at compile time.
If you are using a class, function, etc...inside of your .cpp file without the code or a prototype in that file, you'd better have it inside of the header file, or it wont compile.
Once your compiler figures that all header files have been found and included in their appropriate .cpp files, then it builds the .cpp files into object files, which have an extension of .o. At this point, if you so chose, you could link several of your .o files together and through one route or another create either a .dll file or a .lib file. Otherwise, you can just link the .o files together and create your executable.
So then, what is the difference between a .h file and a .lib/.dll file. Simple, the .h file is a human readable file that must be converted at some point into an object file. A library file on the other hand is a binary file made up of already compiled header and source files.
This means a few things to you.
1. if you're putting all of your code into your header files, then at some point, in which you decide to write a game engine or something where you must distribute your header files for others to use, all of your code will be visible and change-able.
If you however put only your function prototypes in your header files and you put all of your code into a library file, no one can mess with your code.
2. If you have code that changes very little, but use it very often, dont put it into a header file. Unless you're using pre-compiled headers, then every time you compile your software you MAY be recompiling your header files as well(not necessarily). On the other hand, if you put your code into a library file, then when you get ready to build your software, the smaller header files with just the prototypes is compiled with your software, saving time, while the rest of the already compiled code is linked in at the end.
Here's my opinion. Only put structures, classes, defines and prototypes into header files. Put all code into .cpp files, and when capable, compile it into a library for easier use.
As to whether or not you should use a static or dynamic library, that depends on whether you want to distribute a larger file, or more files. Also, if you use static libraries, you're loading the entire contents of the library into memory...more or less. With dynamic, you can choose which content to load and which not to.
phew...there's my 2..er..3 cents.
Best Regards,
Jeromy "Maverick" Walsh
------------------------
"The question isn't how far, the question is do you possess the constitution, the depth of faith, to go as far as is needed?" -Boondock Saints
[edited by - jwalsh on June 12, 2002 11:06:00 PM]
Jeromy Walsh
Sr. Tools & Engine Programmer | Software Engineer
Microsoft Windows Phone Team
Chronicles of Elyria (An In-development MMORPG)
GameDevelopedia.com - Blog & Tutorials
GDNet Mentoring: XNA Workshop | C# Workshop | C++ Workshop
"The question is not how far, the question is do you possess the constitution, the depth of faith, to go as far as is needed?" - Il Duche, Boondock Saints
Sr. Tools & Engine Programmer | Software Engineer
Microsoft Windows Phone Team
Chronicles of Elyria (An In-development MMORPG)
GameDevelopedia.com - Blog & Tutorials
GDNet Mentoring: XNA Workshop | C# Workshop | C++ Workshop
"The question is not how far, the question is do you possess the constitution, the depth of faith, to go as far as is needed?" - Il Duche, Boondock Saints
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement