What's the difference between C/C++ Library and STL C++ Library in XCode?

Question

I'm trying to create a C++ library in Xcode and I'm not sure whether to choose the C/C++ Library or the STL C++ Library option? I noticed that the STL C++ Library option doesn't let you create a static library and force you to create a dynamic library. However, the C/C++ Library option also lets you create a dynamic library in addition to creating a static library.

What's the difference between these two options and when should I use each? I read the descriptions below the options but unfortunately they are not terribly helpful.

On another note, why is static library file different from dynamic library file at all? It seems that the difference is primarily in how the library is found (packaged with your app vs. relying on presence on the target machine), not in the functioning or code of the library itself. It would be great if someone can clarify this.

Answer 1

A statically linked library cannot be loaded at run-time but must be incorporated into your binary file when you link your executable. This means that all entry points to the code in the statically linked library are well defined and their addresses will not change relative to the start of your executable code (thus "static").

With dynamically loaded libraries, there is no way of knowing where the code will be, so when the library is loaded at run-time, a certain amount of performance overhead is necessary to "bind" the loaded code. Essentially, the linking is deferred to run-time, which is why it is also sometimes known as "late binding".

Which you choose to implement depends on your usage requirements. If you want a self-contained executable that the user can simply drag and drop into his applications folder without having to worry about dependencies, statically linking your libraries may be the way to go.

But for larger scaled projects, in apps that provide a ton of functionality, it may be prohibitive and unnecessary to load all the functionality at once. Providing a set of dynamically loadable libraries can both save memory and shorten start-up time. Then, as the user accesses features, the relevant code is loaded, and possibly features that haven't been used in a while can be unloaded.

Additionally, if you make changes to the code, you might be able to simply redistribute the one or two libraries rather than having to re-compile and re-link and re-distribute the entire executable. And need I mention the prospect of plugins?

The differences between the two templates above are subtle. Both compile C according to the GNU99 standard. But the C/C++ Library template sets up xcode to compile C++ according to the C++/GNU++0x "standard". C++/GNU++0x was later officially published as C++/GNU++11 in 2011. Both templates default to using libc++, but the STL C++ Template allows you to select to link against the older libstdc++ instead. Why would you do this? If your code links against libc++ but you are also linking against other libraries that reference libstdc++, and you run across conflicting symbols, you might be able to resolve this by linking against libstdc++ instead. The STL C++ Library template also allows you to request that the compiler stick to the C++11 standard, excluding the GNU++11 extensions, or go back to C++/GNU++98 (if you need to compile legacy code, for example).