C, C++ programming tips
Vishal Patil
Summer 2003
Contents
1
Introduction
3
2
Managing multi-file C/C++ project
4
2.1
Good software engineering practices
. . . . . . . . . . . . . .
4
3
Using Automake and Autoconf
7
3.1
Project directory structure
. . . . . . . . . . . . . . . . . . .
7
3.2
Enabling Portablity
. . . . . . . . . . . . . . . . . . . . . . .
7
3.3
Configuration files in brief
. . . . . . . . . . . . . . . . . . . .
8
3.4
A brief example
. . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.5
Understanding the configure.ac file
. . . . . . . . . . . . . . .
8
3.6
Understanding the Makefile.am file
. . . . . . . . . . . . . . .
9
3.6.1
For each program
. . . . . . . . . . . . . . . . . . . . .
10
3.6.2
For each library
. . . . . . . . . . . . . . . . . . . . . .
11
4
Generating build scripts
12
5
Build options
12
6
Avoiding common errors in C and C++
13
6.1
Identifier clashes between source files
. . . . . . . . . . . . . .
13
6.2
Multiply defined symbols
. . . . . . . . . . . . . . . . . . . .
13
6.3
Redefinitions, redelarations, conflicting types
. . . . . . . . .
14
7
Effective C++ programming
15
7.1
Put the constant on the left in a conditional
. . . . . . . . . .
15
7.2
Handle errors and not bugs
. . . . . . . . . . . . . . . . . . .
15
7.3
Use asserts in debug builds
. . . . . . . . . . . . . . . . . . .
16
1

7.4
Use exceptions
. . . . . . . . . . . . . . . . . . . . . . . . . .
17
7.5
Virtual functions
. . . . . . . . . . . . . . . . . . . . . . . . .
18
7.6
Don’t ignore API function return values
. . . . . . . . . . . .
18
7.7
Be consistent
. . . . . . . . . . . . . . . . . . . . . . . . . . .
18
7.8
Make your code const correct
. . . . . . . . . . . . . . . . . .
18
7.8.1
The many faces of const
. . . . . . . . . . . . . . . . .
18
7.8.2
Understanding the const
cast operator
. . . . . . . . .
19
7.8.3
const and data hiding
. . . . . . . . . . . . . . . . . .
20
8
References
21
2

1
Introduction
This document gives a quick idea about the various aspects of software de-
velopment using C and C++. The document is in an adhoc form and lacks
a proper structure and flow of information. However I shall be revising the
structure from time to time and as I add new information to it.
Note: I hold no responsibility for any damage or failure caused
by using this document.It is very likely that the contents of
the document might change from time to time and might even
be mistaken at some places. Use this document as per your own
discretion.
3

2
Managing multi-file C/C++ project
2.1
Good software engineering practices
The key to better software engineering is to focus away from developing
monolithic applications that do only one job, and focus on developing li-
braries. One way to think of libraries is as a program with multiple entry
points. Every library you write becomes a legacy that you can pass on to
other developers. Just like in mathematics you develop little theorems and
use the little theorems to hide the complexity in proving bigger theorems,
in software engineering you develop libraries to take care of low-level de-
tails once and for all so that they are out of the way everytime you make a
different implementation for a variation of the problem.
On a higher level you still don’t create just one application. You create
many little applications that work together. The centralized all-in-one ap-
proach in my experience is far less flexible than the decentralized approach
in which a set of applications work together as a team to accomplish the
goal. In fact this is the fundamental principle behind the design of the Unix
operating system. Of course, it is still important to glue together the various
components to do the job.
This you can do either with scripting or with
actually building a suite of specialized monolithic applications derived from
the underlying tools.


You've reached the end of your free preview.
Want to read all 21 pages?
- Fall '17
- Software engineering