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

ps, 下面是關(guān)于static 和 dynamic鏈接的一些回答，可以略過(guò)
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?