Linking & more

[DavidScript]

Okay, so I have fairly decent knowledge of C++, but I want to use some libraries that would help me, especially in the near future. I tried linking with some random snippets of directions and tips, but I don't link properly 90% of the time. Can someone help me how to link in Code::Blocks?

Also some other questions:

What's the difference between static linking and dynamic linking?

What is CMake and how does it work?

Thanks

[ultifinitus]

Loaded questions mate- I'll answer the first.

Static linking = no DLL. Dynamic = DLL. Generally a dynamic link will be faster and less resource intensive by a small, sometimes not so small amout. On the other hand it's nicer for distribution if you choose static.

I'll leave how cmake works to others- I don't have the time.

[Disch]

Generally a dynamic link will be faster and less resource intensive by a small, sometimes not so small amout.

eeehhh?

This is the first time I've heard this claim.

[DavidScript]

eeehhh?

This is the first time I've heard this claim.

What do you mean by that?

[JMJAtlanta]

I think what is meant is that with dynamic linking, compiling the application is faster, as some of your library is already compiled. As for runtime speed, dynamic linking is rarely faster than static linking.

EDIT: scratch that first sentence. I am not awake yet this morning.

Okay, I'm half way through my Mountain Dew, so here goes:

linking Code::Blocks - sorry, someone else will have to help you there, as I'm not familiar.

Static linking: Take your program, plus all the libraries you need, and stuff it in one executable (.exe). To share your program with someone else, just give them the 1 big .exe file.

Dynamic linking: Your program compiles into an .exe and is smaller in size, but will not run on another machine unless the other machine has the same shared libraries (Windows calls them DLLs) on it also. And if those shared libraries are a different version than the one you planned on, it may work or it may not. If it doesn't work, you can put the "correct" DLL on the machine, but then other software that may have used that DLL may not work. Hence the term "DLL Hell".

CMake is a program that helps you compile and link your source code into programs. It is a great tool if you distribute your software as source code, and do not want to depend on other people using the same IDE as you. As long as they have CMake and the correct compilers and linkers, they can generate the same executable. You give them the source code and a file that tells CMake how to compile and link it (called a Makefile), and you're golden.

[DavidScript]

So if I were to make a game, would dynamic linking be better based on the fact that 95% of applications I've seen have DLLs along with them?

[shacktar]

No, it won't. "Better" with linking comes down to application specific details. The applications you've seen that have DLLs may have them just because the libraries they used were not available statically.

[Computergeek01]

@ Disch: Ideally, the application would be faster to start because the DLL would already be loaded into memory by the time the program is executed. In my experiance DLL's are NEVER used right so we don't actually see this. Saying that the memory foot print is smaller is sort of cheating because the code IS in memory, it's just not in the private address space of the application.

[Disch]

If you are distributing DLLs with your EXE, it defeats the entire point of having DLLs in the first place. The whole point of having a DLL separate from your EXE is so that only one copy of it exists on a machine, and all programs that use that library can share the same DLL. If every program is providing its own copy, then that's just pointless.

Sure static linking will make the exe bigger, but it will still be smaller than the size of the dynamic exe + dll, and you don't have to worry about the possibilities of missing dlls or mismatching dll versions.

Dynamic linking only really makes sense if:

- You have multiple programs that you are distributing in a single "package" that all share the same lib

or

- You will provide an installer that will install the DLL to a known directory on the user's machine, but only if they don't already have a copy of it installed. (Or there is some such installer available)


On Windows, it's actually kind of tricky to use dlls properly. This is compounded by the fact that C++ doesn't really work well with dlls (a C++ dll compiled in X compiler probably will not work in a program compiled with Y compiler).

So most of the time, on Windows at least, you are much better off statically linking.

[ultifinitus]

eeehhh?

This is the first time I've heard this claim.

orly.

I've heard it quite a few times, one of the only arguments I've heard for dlls. I believe it was when more than one application is utilizing the library. Personally I dislike dlls- and statically link with everything I have a choice to.

[Disch]

I suppose I can see startup being faster if and only if the DLL is already loaded. Otherwise I don't see how dynamic linking could be anything but same speed or slower.

[ultifinitus]

Well I could certainly be wrong, in fact, it seems that it takes an extra jump in memory to even use a DLL- here's a stackoverflow discussion on the subject.

http://stackoverflow.com/questions/1993390/static-linking-vs-dynamic-linking

[DavidScript]

Well I could certainly be wrong, in fact, it seems that it takes an extra jump in memory to even use a DLL- here's a stackoverflow discussion on the subject.

http://stackoverflow.com/questions/1993390/static-linking-vs-dynamic-linking

I found some more info looking through that site and found that dynamic linking is useful when you're making a game with periodic patches

http://stackoverflow.com/questions/3931607/what-should-we-consider-to-use-either-static-linking-and-dynamic-linking

I guess that dynamic linking is the way to go




And back to my main question: How do you link in Code::Blocks (this sounds really stupid after all that)?

[ultifinitus]

I don't think that dynamic linking is the way to go. I'd go with static personally. But your choice =]

To link in code::blocks, you click on project->build options->linker settings and either add your .a files or input your linking string.

[Disch]

I found some more info looking through that site and found that dynamic linking is useful when you're making a game with periodic patches

It depends on what you're patching. If you're patching the library, then yes. If you're patching the executable, then not really.