Hi,

I am starting some c++ programming. I have managed to get a little "Hello World" program going, and it works (yeah!). I have compiled (?) it by using the functions make, compile and build in various orders and one of them worked. I don't remember which one

I was wondering: what is the difference between the build, make and compile functions. What does each one do?

I have read some tutorials, but they all teach you how to do stuff with the language, nothing about the compiler.

(Oh, by the way: i am stuck on a windoze machine at the moment with borland...)

THANKS!!

I assume you're talking about some menu options in the IDE.

Compile just compiles a file. The result is usually an object file (o or obj extension) and you can't do much with them.
Object files need to be linked (with some libaries and sometimes other object files). This is done by the linker.

Make is a tool that - according to rules that you (or the Borland IDE) specify in a so-called makefile - calls the compiler and the linker to create the executable. It i.e. checks if a file was newer than the object file with the same name and will compile/link again if necessary.

I'm not sure about build, it might be make a special 'version' of make that basically forces recompilation and linking of the program.

Compile has some options (when called from the commandline). You can tell it to call the linker, so the result will be an executable.

What exactly does the compiler do, if its results cannot be executed? Does it simplify the code, so that it is easier for the linker to connect it with other files and functions?

Why is the linker actually needed? What does it link? Aren't all dependencies declared as

The compiler generates object code. The linker links it with the libraries to create an actual executable. I'm not completely sure how it works in Windows, but I imagine it's similar to *nix in that the linker checks all the library references, sets the stubs up (for anything not statically linked in) and creates the startup code actually needed to make a complete executable.

The include statement doesn't include a library -- it just includes a header file which, in the case of libraries, simply declares the programming interface for the library. The actual binary code is actually stitched together by the linker.

I don't 100% get it, but it seems to make more sense now. Libraries get linked to the object code and "glued" together into an executable. The object code itself is useless by its own.

So, basically, compiling and linking are one process?

the compiler also goes through the pre-processor directives (#include, #if, etc) and all that. the file also needs to be converted to machine level code (1's and 0's in assembly language), the program doesn't actually run like switch-case and all that, that is just to make the programming easier for you. basically, the whole building of the program : c++ code->pre-processor->assembler->linker->executable

A couple of points:

1. As you know, a computer executes a "program", a program is written in a "programming language". So far, so good.

2. Programs are generally either "compiled" or "interpreted".

A .bat file, for example, is "interpreted": Windows reads your .bat file a line at a time, figures out what the commands are, and tries to execute them. Basic, Perl and PHP are other examples of "interpreted" languages: your programming commands start out as text, and they pretty much stay in their original text form as they're executed.

A .exe file, on the other hand, was "compiled". One or more tools went through an elaborate process to translate your "source" commands into machine language that can be executed directly by the system.

Since "Compiled" programs do not have to be "Interpreted" on-the-fly, they are correspondingly much faster (and often - but not always - much more compact).

3. "Compiling" a program is (at least!) a two step process:
a) Convert source code into object code
b) "Glue" the object code together with system libraries into a viable executable.

4. Using "make" (a standard tool) is one way to accomplish this process.

Using an IDE such as Borland BC++ or Visual Studio is another, equivalent way to
accomplish the same process.

5. The process itself - the steps you need to take to translate source code into
a viable executable - is called "the build".

'Hope that helps .. PSM

PS:
The lines "include <iostream>" and "using namespace std;" have nothing whatsoever to do with linking. "include" is one of the "pre-processor directives" that airswit mentioned above - it's something that occurs before the compiler even looks at your source code. The "using" statement is a C++ compiler instruction.

As stated in the Borland C++ Builder Help (Copyright (c) Borland Software, portions: toolsfactory GmbH):

Use Project|Make project to compile all files in the current project that have changed since the last build into a new executable file, dynamic link library (.DLL), resource file (.RES), or so on. This command is similar to the Build command, except that Project|Make builds only those files that have changed since the last compile, whereas Build rebuilds all files whether they have changed or not.

Here is a (very simplified) explanation of the compiling/linking process:

1. The compiler takes in your source code, and processes it and turns it into machine language, almost. In your "Hello, World!" program, that machine language consists of a block of data with the string "Hello, World!" in it, and instructions to put a pointer to that block of data on the stack, call the printf function, get the return value, and exit the program. Problem is, at this stage, the compiler knows nothing of printf, as it is in a different library (libc). That is an unresolved reference. So it puts a list of unresolved references into a file, along with a list of where those references are used, along with this almost machine language, into a file. That is your obj file.

2. The linker takes in this obj file, along with libc (where printf lives), and sees that printf is an unresolved reference in the obj file. It takes the printf machine code, the "Hello, World!", and puts them into another file, at the same time fixing the call instruction to point to the printf code. Now it has a complete set of machine language. It also puts some other stuff to be used by the loader code into this file. This file is the executable.

3. When the executable is run, the loader reads in the file, processes it according to the extra stuff the linker put in the file, puts the machine code somewhere in memory, and calls that machine location, thereby executing your code.

Like I said, this is a very simplified explanation. In real life the printf code lives in a .dll or .so, and doesn't even get linked until the loading stage. But that's another explanation altogether.

In order to avoid thread necromancy in the future, before posting a reply, please, take your time, and check the date of the last post. This particular thread has been started 4 years ago.

3 members found this post helpful.

Ah crap! All that typing and WWNEXC has probably already grasped the whole concept and more.

What a waste of my time.

I'll be checking that date from now on!

I'm sorry.
Me too will check the time next time.