0

I'm new to C++. When I write a program I expect it to compile into a standalone executable, but with C++ there's a lot of talk about dynamic and static linking. From what I gather this means the separate libraries used are compiled separately and linked rather than compiled together.

Compile time is not an issue for me. I don't see why I want to link to a library rather than compile it directly with my code as one. Surely that would result in better optimization and inlining.

A perfect example is tcmalloc. I'd like to to use the tcmalloc memory allocator, not the profiler that is bundled with, and not link to it statically or dynamically, but compile it directly into my program with inlining optimizations.

How do I do that?

Alasdair
  • 13,348
  • 18
  • 82
  • 138
  • 5
    What you want *is* static linking. That will take all libraries that are capable of being statically linked, and insert the code into the executable program. – Some programmer dude Apr 29 '21 at 14:03
  • 1
    @Someprogrammerdude It'll insert the already compiled code, as function calls, without inlining optimizations though, right? – Alasdair Apr 29 '21 at 14:05
  • I'll bet that if you had to recompile all the libraries that you're using as part of every build, build time would become an issue for you. – Pete Becker Apr 29 '21 at 14:06
  • @PeteBecker I only need to do it once at release. For development static linking is fine. I need every ounce of additional performance and can wait for 6 hours for it to build. – Alasdair Apr 29 '21 at 14:07
  • 1
    Considering the probable case that your lib code does not change very often i don't see an issue with the compile time. Every reasonable build system is expected to compile only the changed parts of the software. So, even if you compile your own project 100x/day, the lib code will only needed to be recompiled here and there. – Wör Du Schnaffzig Apr 29 '21 at 14:11
  • There are some OS/runtime libraries needed for every C++ program, are you also looking into linking those statically? – SergeyA Apr 29 '21 at 14:12
  • 1
    There is absolutely no difference between, say, compiling three ,cpp files and then linking the resulting three .obj files together; and combining two of those files into a static library, and then linking one .obj file and one .lib file. A static library is nothing more than a collection of object files, archived together for ease of management. "Inlining optimizations" are achieved by putting code into **header** files, so the compiler can see the implementation at the point where the function is called. – Igor Tandetnik Apr 29 '21 at 14:12
  • `Surely that would result in better optimization and inlining.` <- *citation needed* – SergeyA Apr 29 '21 at 14:12
  • 1
    You can use [LTO](https://en.wikipedia.org/wiki/Interprocedural_optimization) with static linking. As people already mentioned, there's no difference between statically linking those libraries and including the sources of those libraries into your build. – icebp Apr 29 '21 at 14:18
  • And regardless, I didn't ask for opinions. I asked a very clear technical question. – Alasdair Apr 29 '21 at 14:28
  • Also what if my release has a different target architecture than my development? How useful is static linking then? – Alasdair Apr 29 '21 at 14:29
  • You can't statically or dynamically link different target architectures, and sometimes not even different compile flags (like optimization level). A static library is literally a collection of object files, no more, no less. Off-topic: jemalloc is arguably better (faster) than tcmalloc. Also, sometimes inlining too much is bad for performance. It's a good idea to *not* inline malloc and free. – rustyx Apr 29 '21 at 18:26
  • @rustyx, thanks! That's what I thought. So basically I can't statically link even if I wanted to. Regarding tcmalloc, I recently benchmarked it against je and others, and tc was better by far in every test case. je and hoard were not much better than std. – Alasdair Apr 30 '21 at 03:57

1 Answers1

0

Okay, a part of C++ programming is the use of libraries. Unless you're doing embedded programming or something weird, you will probably never write a C++ program that doesn't include at least some other libraries. If nothing else, you get the standard system libraries so you have access to things like cout, fopen, or whatever system calls you're trying to make.

If you want to have code inlining for performance reasons, then it should appear in your include files as part of your definitions.

There's no advantage and a whole ton of disadvantages to "compile everything together". First off, you probably don't have access to most of the code. Then you'd have to know what code to include and cat it all into one huge-ass file. Then compile that sucker and come back tomorrow.

Joseph Larson
  • 8,530
  • 1
  • 19
  • 36
  • Thanks... it doesn't answer my question though. That last part "knowing what to include" that would be my question. – Alasdair Apr 30 '21 at 03:54