Will a binary include methods that are not called in the source code?

Question

[Potentially misleading title, but I'm not sure how best to word it.]

Theoretical question on compilers and language design.

Say I'm re-implementing a method in a code base. Instead of removing or commenting out the method that I'm re-implementing I leave it where it is, for reference and testing purposes, and just remove all the calls to it. Something like the following (in C-style pseudo code):

public void aMethodToCallFooVariants()
{
   // oldFoo();
   newFoo();
}

private void oldFoo ()
{
   // Some code here that's not very good
}

private void newFoo ()
{
   // Some better code here
}

newFoo is called by the method that originally called oldFoo, meaning that oldFoo is no longer called anywhere in the source code, but it still in the listing.

Are compilers smart enough such that when I run my build script, the code for oldFoo isn't included in the compiled binary, or will oldFoo still be included but not called anywhere? I can understand if public method will still be included, they could be called by code that is external to the compiled binary (especially if it's compiled as a library). But would the private method still be compiled into the binary?

Answer 1

That depends on the compiler and linker and how well their dead code elimination works. It is important to note however that in a turing-complete language (with reflection) it is undecidable whether a certain piece of code ever gets reached (halting problem hard)

In other words if you use a source control press that delete button and leave a message in the commit and/or mention is in the documentation of the new method.

You can use a transition period where you mark the method deprecated and have the compiler issue a warning each time the old version is used.

Answer 2

With C and C++ compilers, the answer is yes - when a code unit is compiled into object code (by the compiler) all functions are listed explicitly. The linker then takes each of these object files and resolves the references to the functions - and all the functions that are left over after this linkage step, can be discarded. This is especially useful for static libraries where you only want a small part of the lib to be included, the rest is ignored and not linked into the final binary.

(obviously this doesn't happen for dynamic libraries, in this case the stubs that are present in the import library are not linked in).