Escolar Documentos
Profissional Documentos
Cultura Documentos
Windows
The commands and process of compiling is different for different compilers.
Borland 5.5 Compiler and command-line tools
The free Borland 5.5 Compiler and command-line tools has, so far, been a great success. At this
time of writing, less than a month after we made it available, we have had hundreds of thousands
of downloads.
I have also received hundreds of emails asking me how to install and use these tools but there is
not really an install, per se. Rather, simply unzip the contents of the package and you are almost
ready to go.
First, let's look at the directory structure. The root, by default is called BCC55. Under this
directory you will find:
Bin
Examples
Help
Include
Lib
Bin
Bin is short for binaries. Under this directory you will find all of the command-line tools (as well
as RTL and STL dynamic libraries). These are 32-bit Windows exectuable, command-line
programs, which means if you double click on one of them from Windows Explorer you are
likely to see a flashing DOS box, that comes up and immediately goes away. These applications
are meant to be run from within a DOS shell. Meaning, you need physically move to the Bin
directory and type the name of the program that you want to run (unless this directory is first in
your path).
For example, if I were to run the compiler bcc32.exe without any arguments I would get a dump
of it's version and command-line options as shown.
[f:\borland\bcc55\bin]bcc32
Borland C++ 5.5 for Win32 Copyright (c) 1993, 2000 Borland
Syntax is: BCC32 [ options ] file[s] * = default; -x- = turn switch x off
-3
* 80386 Instructions
-4
80486 Instructions
-5
Pentium Instructions
-6
-Ax
Disable extensions
-B
-C
-Dxxx
Define macro
-Exxx
-Hxxx
-Ixxx
-K
-Lxxx
Libraries directory
-M
-N
-Ox
Optimizations
-P
-R
-RT
* Generate RTTI
-S
-Txxx
-Uxxx
Undefine macro
-Vx
-X
-aN
Align on N bytes
-b
-c
Compile only
-d
-exxx
-fxx
-gN
-iN
-jN
-k
-lx
-nxxx
-oxxx
-p
Pascal calls
-tWxxx
-u
* Underscores on externs
-v
-wxxx
Warning control
-xxxx
Exception handling
-y
-zxxx
Examples
The examples directory contains one directory called stdlib. In that directory are a number of
source files that use various classes and algorithms available in the STL. Also, there is a makefile
that builds all of the examples. More on that later.
Help
There is one Windows help file. It is called bcb5tool.hlp. You can double-click on it from
Windows Explorer to read it. The following is a snapshot of one of the entries in the help file
which explains what each of the command-line tools do.
File
Description
BCC32.EXE
BPR2MAK.EXE
Converts project file from XML to MAKE file format for use with commandline tools
BRC32.EXE
BRCC32.EXE
CPP32.EXE
GREP.EXE
ILINK32.EXE
IMPDEF.EXE
IMPLIB.EXE
MAKE.EXE
Make utility
RLINK32.DLL
TDUMP.EXE
TLIB.EXE
TLIBIMP.EXE
(Type Library Import) tool. Takes existing type libraries and creates C+
+Builder Interface files. Incorporated into the Type Library editor.
TOUCH.EXE
Converts Microsoft Visual C++ 5.0 and 6.0 project (.DSP) and workspace
(.DSW) files to their equivalent Borland C++Builder files
Include
This directory contains all of the header files for the Borland RTL, the STL (RW) and the
Windows SDK.
Lib
This directory contains all of the static and import library files and startup code modules.
Difference between Header files and Libraries
Generally, a header file notifies the compiler of certain things (mostly their existence or
declarations) so that the compiler can correctly build a single translation unit (such as a single C
file). A library file is the actual executable code that does the work as specified in that header
file. This is linked in by the linker to provide the actual functionality (the definitions rather than
just the declarations).
Putting it all together
So, now that you are armed with all this information you are probably wondering "How do I turn
my source code into a program?" We will start with the simplest case of a single source file,
console program. Here is the source code of a file called simple.cpp that I wrote in the text
editor, notepad:
#include <stdio.h>
int main(void)
{
printf("Output from running program");
return 0;
}
To build this into a program we only need to call the compiler. However, the compiler needs to
know what source file to build and where to find the header files and the library files. We pass
these to the compiler as command line options as shown:
bcc32 -If:\Borland\bcc55\include -Lf:\Borland\bcc55\Lib simple.cpp
The resulting program is called simple.exe and can be run by typing simple at the command-line.
Now, let's look at the case of a console program with two source modules. simple.cpp will
contain our entry point main and will call a function defined in the other module, funcs.cpp.
simple.cpp
#include "funcs.h"
int main(void)
{
return PrintSomeOutput("Output from running program");
}
funcs.h
funcs.cpp
#include <stdio.h>
int PrintSomeOutput(char* output)
{
printf(output);
return 0;
}
To build this, simply add funcs.cpp to the previous compiler command-line as such:
bcc32 -If:\Borland\bcc55\include -Lf:\Borland\bcc55\Lib simple.cpp funcs.cpp
So what happens if you have a bunch of different include and library directories. Or hundreds of
source files. As you can imagine the command-line for this would be huge. You have two
choices. Wrap up all of these commands into a batch file or use a makefile. Makefiles are
prefferred, and next week we will delve into this. In the meantime, take a look at the makefile in
the Examples\StdLib directory as we will be dissecting it.
Console applications accept various parameters and switches that are typed in at the command
line or from a batch file. Though not as common under Windows, many operating systems, such
as UNIX or Linux use this format. Use of Borland C++ 5.5 assumes the user is comfortable
working within a console interface. Typically, the user will run an application such as edit or
Notepad to actually write their program (an editor is not supplied with the compiler). When the
user wishes to compile source code, they save the file out as "filename.cpp" and then use the
command-line tools from within DOS to compile and create an executable. Like so:
bcc32 filename.cpp
The first argument is name of the compiler tool, and the second argument contains the C++
source file. This application will attempt to compile the source code and will notify the user of
any errors in the code. If no errors are found it will create an executable. To display information
regarding the various switches, type "bcc32"
Step-by-step Instructions for Configuring your System for the Command-Line Compiler
Configuring the system environment:
{
cout << "Hello." << endl;
return 0;
}
8. Save the changes (Alt-F then hit S, if using edit).
9. Exit edit. (Alt+F then press X, if using edit).
Now, compile the program to create an executable:
10. Type "bcc32 hello.cpp"
Finally, you may run the application you created.
11. Type "hello"
(The output will appear below your last command line.)
Note: The programming process begins with the creation of a text file which contains the
statements of the program in a programming language. (This source file is a text file, usually
ASCII, which can be produced with a text editor, such as Windows notepad, or in an Integrated
Design Environment.) This source file is then processed by a special program called a compiler.
Each programming language has its own compiler, and the compiler must be matched to the
hardware and operating system that the new program will run on.
On PCs, the extension of the source file conventionally matches the programming language
used; .c for c programs, .cpp for c++ programs, .pas for pascal programs, .for for FORTRAN
programs, and so on.
The compiler translates the source code into code for the target system, known as object
code. This object code contains the machine instructions for the CPU, and calls to the operating
system API (Application Programming Interface.) Object code is the same for different source
languages, but will usually contain calls to run time subroutines which match the source
language. The object file is not yet executable, however.
On PCs, the extension of the object file is conventionally .obj.
The next step is to process the object file with another special program called a link editor.
The same link editor is used for object modules regardless of the original language in which the
new program was written. Each system has its own linker, however. The output of the link editor,
or linker, is an executable, or runnable, file .
On PCs, the extension of the run file is conventionally .exe. (PCs also use .com as an
extension for run files; these are created from .exe files by an extra step, and not all .exe files can
be converted to .com files.)
For the C++ language, there are two kinds of source files, and two steps to the compile process.
In addition to the main (.cpp) source files, which contain executable statements, there are also
header (.h or .hpp) source files. Header files normally contain only declarations. Since all input
and output in C++ programs is done through library functions, almost all C++ programs use
standard header files, which are supplied with the compiler. Header files should also be written
as part of the source code for modular C++ programs (see below.)
The first step of the compile process is a special preprocessor program. The preprocessor
program reads the source file as text, and produces another text file as output. Source code lines
which begin with the octothorpe character ("#") are actually written not in C++ itself, but in
preprocessor language. Based on these statements, the preprocessor makes substitutions of one
character string for another, substitutes the text of a header file for #include statements, and even
expands some function calls into other text. The substitutions can be conditional. The output of
the preprocessor is a text file which does not contain any preprocessor statements, which is ready
to be processed by the C++ compiler itself.
The link editor also combines the object file with library routines (supplied with the compiler) to
produce the executable file.
When modular programming is used, the source code is divided into two or more source files.
These files are compiled separately, producing multiple object files. The object files can be
combined by the link editor into the same executable file.
The resource script is separately compiled by a resource compiler into a resource object file,
which is then combined with the .exe file by a resource linker.
LINUX
The commands and process of compiling is different for different compilers.
How to write and compile C++ programs
In order to run a program and see it doing wonderful things, you should first write the
program. The program can be written in any text editor, such as vi and emacs in Unix
environment and using command prompt in DOS. There are also several Integrated Development
Environment (IDE) packages available which provide a complete programming environment for
C++ in which you can write, compile, run, and debug your program. C++ programs are saved
with extensions .C, .cc, .cpp, .cxx depending on the platform you are working upon. Once you
have saved a program, next stage is compiling it using a compiler which converts your C++
program into the object code which the computer can understand.
Installing compilers is one of the easiest things there out at Linux. It may seem a bit tough and
complicated in the beginning but apt-get(Ubuntu) and Synaptic Package Manager(Ubuntu)
simplify your work a lot. In ubuntu g++ compiler (i.e build-essential package) is installed by
default. As a newbie developer you would require a C/C++ and a Java compiler. Installing them
is a matter of few commands.
The GNU C and GNU C++ Compiler:
The GNU C compiler is also called gcc and C++ is called g++. You may also require the GNU
make utility. All of them can get installed by getting the build-essential package. Just use this
command:
sudo apt-get install build-essential
if above package not available download GNU C++ compiler (from Ubuntu Software centre for
Ubuntu).
Compile using g++ compiler
If you are using UNIX environment and using g++ compiler, then compiling your C++ program
is simple. After you have saved the program file, simply type the command
g++ program.cc o program
where program is the name of the program. For example the name of our first program is first,
then save it using extension first.cc. To compile, type
g++ first.cc o first (does both compiling and linking here.)
To run the program, type first or ./first at the command prompt and your program will run.
Note:
1. If using #include <iostream.h> gives error (fatal error: iostream.h : no such file or
directory) use #include <iostream>. <iostream.h> is deprecated - it is the original
Stroustrup version, and < iostream> is the version from the standards committee.
Generally compilers point them both to the same thing, but some new compilers won't
have the older one. In some odd cases they will both exist and be different (to support
legacy code) and you then must be specific.
2. using namespace std: All the elements of the standard C++ library are declared within
what is called a namespace, the namespace with the name std. So in order to access its
functionality we declare with this expression that we will be using these entities. This line
is very frequent in C++ programs that use the standard library, and in fact it will be
included in most of the source codes included in these tutorials. If scope error is given
like 'cout' not declared in the scope add using namespace std; after
#include<iostream.h> i.e for example
#include <iostream>
using namespace std;
int main(void)
{
cout << "Hello." << endl;
return 0;
}
This explanation is going to be targeted at using g++ (its generally the default compiler on Linux
system and it is the default compiler underneath Mac OS X's xCode). Microsoft's Visual Studio
also has a C++ compiler that you can access, called cl.exe, and it provides many of the same
options that g++ provides albeit via different command switches. To start with, you run g++
simply by typing g++ at a command prompt (for Mac OS X that normally involves starting
Terminal.app and on Linux you can start up a similar terminal program, Gnome and KDE both
provide one). When you run g++ on its own with no arguments you should get something similar
to this as a response:
g++: no input files.
To actually compile a C++ file, you need to call g++ with the filename containing the C++ code.
So if your code is contained in a file called main.cpp, to compile it, just type 'g++ main.cpp'.
Assuming you have no errors, this will produce an executable file called '\1 (on Linux and Mac
OS X). To run your resulting executable, just type './a.out'. This is about the most basic thing
you can do to produce an executable from your C++ code. Since the number of options provided
by g++ is vast, only a few basic options will be covered here and you can look into other options
as you see fit.
The first option to look at is the -o switch that g++ provides. In the example above, the
compiler extracted the code from your file and created a new file called 'a.out'. If you want to
override this default name and instead call the output executable file main, you would execute
the following command 'g++ main.cpp -o main'. When g++ finishes, it will have created an
output file called 'main' instead of 'a.out' and to run it, you just type './main'. You should try
some different examples to get familiar with how this works.
The second option that is worth looking at is the -Wall switch. C++ is complex language
and it can often be unforgiving. So C++ compiler writers often look for ways to help
programmers avoid writing bugs. The -Wall switch that g++ provides is one such way. What the
-Wall flag does is tell g++ to generate warnings for any code that it encounters that is
syntactically correct but looks suspicious semantically. In many cases -Wall can uncover bugs
before you even run the program because they are common mistakes and g++ can know to look
for them. Here are some useful examples.
#include <iostream>
using namespace std;
int main (void)
{
int a = 3;
cout << "++a is: " ++a << " and a++ is: " << a++ << endl;
return 0;
}
At first glance, this looks ok but this actually contains the worst type of bug possible in C++, the
dreaded "undefined behavior"! Assuming the code above is in a file called main.cpp, the
command 'g++ main.cpp -o main' returns with no complaints. However, compiling with
'g++ -Wall main.cpp -o main' gives the following output:
main.cpp: In function
'int main()':
The source files, in the example the files hello.C and message.C, contain C++ source
code instructions written in the source language, in this case C++. Such instructions can be
divided into two kinds:
o
definitions, which, roughly, cause the compiler to "output" something, e.g.
assembler instructions or memory reservation for variables. E.g. the following C++ statements
are definitions.
int v;
int f() { ... }
o
Static libraries
In the example, the linker looked at the standard library in
/usr/lib/libstdc++.a. (by convention, files with a ".a" suffix are static libraries). This means that
the linker will copy the code (or data) corresponding to the unresolved references from the
library file, and add them to the executable file. Simply put, the linker will extract those object
files from the library (a library can be thought of as a collection of object files) that are
(recursively) needed by the other files and add them to the resulting executable file. This process
is called static linking (with libraries).
If, after linking, we were to remove the library file /usr/lib/libstdc++.a, the executable
file hello would still work.
It is possible to create your own libraries, see Section 3.3.
1.
2.
3.
4.
Static linking has the disadvantage that it increases the size of the executable file. E.g. almost
every statically linked executable file contains its own copy of the C++ iostream code, which
may use a considerable amount of disk space. Also, if a new version of the library is available,
statically linked executable files will need to be linked again in order to use the new version of
the library.
An alternative way to link with libraries is to use so-called dynamic (also called shared) libraries.
Conventionally, dynamic library files have names ending with ".so", like /usr/lib/libstdc++.so.
When linking with a dynamic library, the linker does not copy any objects; it just remembers
which parts of which library are needed by the executable file. Thus, dynamically linked
executable files tend to be smaller. At run time, i.e. when the program2 is actually executed,
the dynamic loader will step in and add the missing parts of the dynamic library to the program.
To find, at run time, the appropriate library, the dynamic loader (called ld.so under Linux)
proceeds as follows:
First, it is possible to store a runpath in the executable file. This runpath is a list (much
like the PATH shell variable) of directories, separated by colons (":"). If such a runpath exists,
the dynamic loader will try to find any needed shared libraries in each of the runpath directories.
If the previous step fails, the dynamic loader will try to find the libraries in the directories
mentioned in the LD_LIBRARY_PATH shell variable, if it exists. Also
the LD_LIBRARY_PATH variable contains a list of directories, separated by colons (":"). Note
that the value of LD_LIBRARY_PATH is ignored for setuid/setgid programs.
Under Linux, try to find the libraries in /etc/ld.so.cache which contains a compiled list of
candidate libraries. See also the ldconfig command.
If any libraries remain to be found, the dynamic loader will look for them in the
directories /lib and /usr/lib.
The procedure above is very flexible: e.g. if the runpath is not used, it is possible, by simply
redefining LD_LIBRARY_PATH, to run the same program with a different version of a shared
library.
You can used the ldd command to find out which shared libraries are needed by an executable
file and where they would be found (using the current definition of LD_LIBRARY_PATH).
tinf2% ldd hello
libstdc++.so.2.9.0 => /usr/lib/libstdc++.so.2.9.0
libm.so.1 => /usr/lib/libm.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
The Tools
We'll start the discussion with a look at the Linux programming tools g++, ar, make, and gdb: