A Quick Introduction To

A Quick Intro duction to C

Tom Anderson

If programming in Pascal is like b eing put in a straightjacket then program

ming in C is like playing with knives and programming in C is like juggling

chainsaws

Anonymous

Intro duction

This note intro duces some simple C concepts and outlines a subset of C that is easier

to learn and use than the full language Although we originally wrote this note for explaining

the C used in the Nachos pro ject I b elieve it is useful to anyone learning C I assume

that you are already somewhat familiar with C concepts like pro cedures for lo ops and

p ointers these are pretty easy to pick up from reading Kernighan and Ritchies The C

Programming Language

I should admit up front that I am quite opinionated ab out C if that isnt obvious

already I know several C purists an oxymoron p erhaps who violently disagree with

some of the prescriptions contained here most of the ob jections are of the form How could

you have p ossibly left out feature X However Ive found from teaching C to nearly

undergrads over the past several years that the subset of C describ ed here is pretty

easy to learn taking only a day or so for most students to get started

The basic premise of this note is that while ob jectoriented programming is a useful way

to simplify programs C is a wildly overcomplicated language with a host of features

that only very very rarely nd a legitimate use Its not to o far o the mark to say that

C includes every programming language feature ever imagined and more The natural

tendency when faced with a new language feature is to try to use it but in C this

approach leads to disaster

Thus we need to carefully distinguish b etween i those concepts that are fundamental

eg classes memb er functions constructors ones that everyone should know and use

ii those that are sometimes but rarely useful eg single inheritance templates ones

that b eginner programmers should b e able to recognize in case they run across them but

avoid using in their own programs at least for a while and iii those that are just a bad idea

and should b e avoided like the plague eg multiple inheritance exceptions overloading

references etc

Of course all the items in this last category have their prop onents and I will admit that

like the hated goto it is p ossible to construct cases when the program would b e simpler

This article is based on an earlier version written by Wayne Christopher

using a goto or multiple inheritance However it is my b elief that most programmers will

never encounter such cases and even if you do you will b e much more likely to misuse the

feature than prop erly apply it For example I seriously doubt an undergraduate would need

any of the features listed under iii for any course pro ject at least at Berkeley this is true

And if you nd yourself wanting to use a feature like multiple inheritance then my advice is

to fully implement your program b oth with and without the feature and cho ose whichever

is simpler Sure this takes more eort but pretty so on youll know from exp erience when a

feature is useful and when it isnt and youll b e able to skip the dual implementation

A really go o d way to learn a language is to read clear programs in that language I have

tried to make the Nachos co de as readable as p ossible it is written in the subset of C

describ ed in this note It is a go o d idea to lo ok over the rst assignment as you read this

intro duction Of course your TAs will answer any questions you may have

You should not need a b o ok on C to do the Nachos assignments but if you are curious

there is a large selection of C b o oks at Co dys and other technical b o okstores My wife

quips that C was invented to make researchers at Bell Labs rich from writing How to

Program in C b o oks Most new software development these days is b eing done in

C so it is a pretty go o d b et youll run across it in the future I use Stroustrups The

C Programming Language as a reference manual although other b o oks may b e more

readable I would also recommend Scott Meyers Eective C for p eople just b eginning

to learn the language and Copliens Advanced C once youve b een programming in

C for a couple years and are familiar with the language basics Also C is continually

evolving so b e careful to buy b o oks that describ e the latest version currently I think

C in C

To a large extent C is a sup erset of C and most carefully written ANSI C will compile

as C There are a few ma jor caveats though

All functions must b e declared b efore they are used rather than defaulting to typ e

int

All function declarations and denition headers must use newstyle declarations eg

extern int fooint a char b

The form extern int foo means that foo takes no arguments rather than argu

ments of an unsp ecied typ e and numb er In fact some advise using a C compiler

even on normal C co de b ecause it will catch errors like misused functions that a normal

C compiler will let slide

If you need to link C ob ject les together with C when you declare the C functions

for the C les they must b e done like this

extern C int fooint a char b

Otherwise the C compiler will alter the name in a strange manner

There are a numb er of new keywords which you may not use as identiers some

common ones are new delete const and class

Basic Concepts

Before giving examples of C features I will rst go over some of the basic concepts of

ob jectoriented languages If this discussion at rst seems a bit obscure it will b ecome

clearer when we get to some examples

Classes and ob jects A class is similar to a C structure except that the denition

of the data structure and all of the functions that op erate on the data structure are

group ed together in one place An object is an instance of a class an instance of the

data structure ob jects share the same functions with other ob jects of the same class

but each ob ject each instance has its own copy of the data structure A class thus

denes two asp ects of the ob jects the data they contain and the behavior they have

Memb er functions These are functions which are considered part of the ob ject and

are declared in the class denition They are often referred to as methods of the class

In addition to memb er functions a classs b ehavior is also dened by

a What to do when you create a new ob ject the constructor for that ob ject in

other words initialize the ob jects data

b What to do when you delete an ob ject the destructor for that ob ject

Private vs public memb ers A public memb er of a class is one that can b e read

or written by anyb o dy in the case of a data memb er or called by anyb o dy in the

case of a memb er function A private memb er can only b e read written or called by

a memb er function of that class

Classes are used for two main reasons it makes it much easier to organize your

programs if you can group together data with the functions that manipulate that data and

the use of private memb ers makes it p ossible to do information hiding so that you can

b e more condent ab out the way information ows in your programs

Classes

C classes are similar to C structures in many ways In fact a C struct is really a

class that has only public data memb ers In the following explanation of how classes work

we will use a stack class as an example

Memb er functions Here is a partial example of a class with a memb er function

and some data memb ers

class Stack

public

void Pushint value Push an integer checking for overflow

int top Index of the top of the stack

int stack The elements of the stack

void

StackPushint value

ASSERTtop stack should never overflow

stacktop value

This class has two data memb ers top and stack and one memb er function Push

The notation classfunction denotes the function memb er of the class class In the

style we use most function names are capitalized The function is dened b eneath it

As an aside note that we use a call to ASSERT to check that the stack hasnt overowed

ASSERT drops into the debugger if the condition is false It is an extremely go o d

idea for you to use ASSERT statements lib erally throughout your co de to do cument

assumptions made by your implementation Better to catch errors automatically via

ASSERTs than to let them go by and have your program overwrite random lo cations

In actual usage the denition of class Stack would typically go in the le stackh

and the denitions of the memb er functions like StackPush would go in the le

stackcc

If we have a p ointer to a Stack ob ject called s we can access the top element as

stop just as in C However in C we can also call the memb er function using the

following syntax

sPush

Of course as in C s must p oint to a valid Stack ob ject

Inside a memb er function one may refer to the memb ers of the class by their names

alone In other words the class denition creates a scop e that includes the memb er

function and data denitions

Note that if you are inside a memb er function you can get a p ointer to the ob ject you

were called on by using the variable this If you want to call another memb er function

on the same ob ject you do not need to use the this p ointer however Lets extend

the Stack example to illustrate this by adding a Full function

class Stack

public

void Pushint value Push an integer checking for overflow

bool Full Returns TRUE if the stack is full FALSE otherwise

int top Index of the lowest unused position

int stack A pointer to an array that holds the contents

bool

StackFull

return top

Now we can rewrite Push this way

void

StackPushint value

ASSERTFull

stacktop value

We could have also written the ASSERT

ASSERTthisFull

but in a memb er function the this is implicit

The purp ose of memb er functions is to encapsulate the functionality of a typ e of ob ject

along with the data that the ob ject contains A memb er function do es not take up

space in an ob ject of the class

Private memb ers One can declare some memb ers of a class to b e private which are

hidden to all but the memb er functions of that class and some to b e public which are

visible and accessible to everyb o dy Both data and function memb ers can b e either

public or private

In our stack example note that once we have the Full function we really dont

need to lo ok at the top or stack memb ers outside of the class in fact wed rather

that users of the Stack abstraction not know ab out its internal implementation in case

we change it Thus we can rewrite the class as follows

class Stack

public

void Pushint value Push an integer checking for overflow

bool Full Returns TRUE if the stack is full FALSE otherwise

private

int top Index of the top of the stack

int stack The elements of the stack

Before given a p ointer to a Stack ob ject say s any part of the program could access

stop in p otentially bad ways Now since the top memb er is private only a memb er

function such as Full can access it If any other part of the program attempts to

use stop the compiler will rep ort an error

You can have alternating public and private sections in a class Before you sp ecify

either of these class memb ers are private thus the ab ove example could have b een

written

class Stack

int top Index of the top of the stack

int stack The elements of the stack

public

void Pushint value Push an integer checking for overflow

bool Full Returns TRUE if the stack is full FALSE otherwise

Which form you prefer is a matter of style but its usually b est to b e explicit so that

it is obvious what is intended In Nachos we make everything explicit

What is not a matter of style all data memb ers of a class should b e private All

op erations on data should b e via that class memb er functions Keeping data private

adds to the mo dularity of the system since you can redene how the data memb ers

are stored without changing how you access them

Constructors and the op erator new In C in order to create a new ob ject of typ e

Stack one might write

struct Stack s struct Stack mallocsizeof struct Stack

InitStacks

The InitStack function might take the second argument as the size of the stack to

create and use malloc again to get an array of integers

The way this is done in C is as follows

Stack s new Stack

The new function takes the place of malloc To sp ecify how the ob ject should b e

initialized one declares a constructor function as a memb er of the class with the name

of the function b eing the same as the class name

class Stack

public

Stackint sz Constructor initialize variables allocate space

void Pushint value Push an integer checking for overflow

bool Full Returns TRUE if the stack is full FALSE otherwise

private

int size The maximum capacity of the stack

int top Index of the lowest unused position

int stack A pointer to an array that holds the contents

StackStackint sz

size sz

top

stack new intsize Lets get an array of integers

There are a few things going on here so we will describ e them one at a time

The new op erator automatically creates ie allo cates the ob ject and then calls the

constructor function for the new ob ject This same sequence happ ens even if for

instance you declare an ob ject as an automatic variable inside a function or blo ck

the compiler allo cates space for the ob ject on the stack and calls the constructor

function on it

In this example we create two stacks of dierent sizes one by declaring it as an

automatic variable and one by using new

void

test

Stack s

Stack s new Stack

Note there are two ways of providing arguments to constructors with new you put

the argument list after the class name and with automatic or global variables you put

them after the variable name

It is crucial that you always dene a constructor for every class you dene and that

the constructor initialize every data memb er of the class If you dont dene your

own constructor the compiler will automatically dene one for you and b elieve me

it wont do what you want the unhelpful compiler The data memb ers will b e

initialized to random unrep eatable values and while your program may work anyway

it might not the next time you recompile or vice versa

As with normal C variables variables declared inside a function are deallo cated auto

matically when the function returns for example the s ob ject is deallo cated when

test returns Data allo cated with new such as s is stored on the heap however

and remains after the function returns heap data must b e explicitly disp osed of using

delete describ ed b elow

The new op erator can also b e used to allo cate arrays illustrated ab ove in allo cating

an array of ints of dimension size

stack new intsize

Note that you can use new and delete describ ed b elow with builtin typ es like int

and char as well as with class ob jects like Stack

Destructors and the op erator delete Just as new is the replacement for malloc

the replacement for free is delete To get rid of the Stack ob ject we allo cated ab ove

with new one can do

delete s

This will deallo cate the ob ject but rst it will call the destructor for the Stack class

if there is one This destructor is a memb er function of Stack called Stack

class Stack

public

Stackint sz Constructor initialize variables allocate space

Stack Destructor deallocate space allocated above

void Pushint value Push an integer checking for overflow

bool Full Returns TRUE if the stack is full FALSE otherwise

private

int size The maximum capacity of the stack

int top Index of the lowest unused position

int stack A pointer to an array that holds the contents

StackStack

delete stack delete an array of integers

The destructor has the job of deallo cating the data the constructor allo cated Many

classes wont need destructors and some will use them to close les and otherwise

clean up after themselves

The destructor for an ob ject is called when the ob ject is deallo cated If the ob ject

was created with new then you must call delete on the ob ject or else the ob ject will

continue to o ccupy space until the program is over this is called a memory leak

Memory leaks are bad things although virtual memory is supp osed to b e unlimited

you can in fact run out of it and so you should b e careful to always delete what

you allo cate Of course it is even worse to call delete to o early delete calls the

destructor and puts the space back on the heap for later reuse If you are still using

the ob ject you will get random and nonrep eatable results that will b e very dicult

to debug In my exp erience using data that has already b een deleted is ma jor source

of hardtolo cate bugs in student and professional programs so hey b e careful out

there

If the ob ject is an automatic allo cated on the execution stack of a function the

destructor will b e called and the space deallo cated when the function returns in the

test example ab ove s will b e deallo cated when test returns without you having

to do anything

In Nachos we always explicitly allo cate and deallo cate ob jects with new and delete

to make it clear when the constructor and destructor is b eing called For example

if an ob ject contains another ob ject as a memb er variable we use new to explicitly

allo cated and initialize the memb er variable instead of implicitly allo cating it as part

of the containing ob ject C has strange nonintuitive rules for the order in which

the constructors and destructors are called when you implicitly allo cate and deallo cate

ob jects In practice although simpler explicit allo cation is slightly slower and it makes

it more likely that you will forget to deallo cate an ob ject a bad thing and so some

would disagree with this approach

When you deallo cate an array you have to tell the compiler that you are deallo cating

an array as opp osed to a single element in the array Hence to delete the array of

integers in StackStack

delete stack

Other Basic C Features

Here are a few other C features that are useful to know

When you dene a class Stack the name Stack b ecomes usable as a typ e name as

if created with typedef The same is true for enums

You can dene functions inside of a class denition whereup on they b ecome inline

functions which are expanded in the b o dy of the function where they are used The

rule of thumb to follow is to only consider inlining oneline functions and even then

do so rarely

As an example we could make the Full routine an inline

class Stack

bool Full return top size

There are two motivations for inlines convenience and p erformance If overused

inlines can make your co de more confusing b ecause the implementation for an ob ject

is no longer in one place but spread b etween the h and c les Inlines can sometimes

sp eed up your co de by avoiding the overhead of a pro cedure call but that shouldnt

b e your principal concern as a student rather at least to b egin with you should b e

most concerned with writing co de that is simple and bug free Not to mention that

inlining sometimes slows down a program since the ob ject co de for the function is

duplicated wherever the function is called p otentially hurting cache p erformance

Inside a function b o dy you can declare some variables execute some statements and

then declare more variables This can make co de a lot more readable In fact you can

even write things like

for int i i i

Dep ending on your compiler however the variable i may still visible after the end of

the for lo op however which is not what one might exp ect or desire

Comments can b egin with the characters and extend to the end of the line These

are usually more handy than the style of comments

C provides some new opp ortunities to use the const keyword from ANSI C The

basic idea of const is to provide extra information to the compiler ab out how a variable

or function is used to allow it to ag an error if it is b eing used improp erly You should

always lo ok for ways to get the compiler to catch bugs for you After all which takes

less time Fixing a compileragged error or chasing down the same bug using gdb

For example you can declare that a memb er function only reads the memb er data

and never mo dies the ob ject

class Stack

bool Full const Full never modifies member data

As in C you can use const to declare that a variable is never mo died

const int InitialHashTableSize

This is much b etter than using define for constants since the ab ove is typ echecked

Inputoutput in C can b e done with the and op erators and the ob jects cin

and cout For example to write to stdout

cout Hello world This is section

This is equivalent to the normal C co de

fprintfstdout Hello world This is section dn

except that the C version is typ esafe with printf the compiler wont complain if

you try to print a oating p oint numb er as an integer In fact you can use traditional

printf in a C program but you will get bizarre b ehavior if you try to use b oth

printf and on the same stream Reading from stdin works the same way as writing

to stdout except using the shift right op erator instead of shift left In order to read

two integers from stdin

int field field

cin field field

equivalent to fscanfstdin d d field field

note that field and field are implicitly modified

In fact cin and cout are implemented as normal C ob jects using op erator over

loading and reference parameters but fortunately you dont need to understand

either of those to b e able to do IO in C

Advanced Concepts in C Dangerous but Occa

sionally Useful

There are a few C features namely single inheritance and templates which are easily

abused but can dramatically simplify an implementation if used prop erly I describ e the

basic idea b ehind these dangerous but useful features here in case you run across them

Feel free to skip this section its long complex and you can understand of the co de

in Nachos without reading this section

Up to this p oint there really hasnt b een any fundamental dierence b etween program

ming in C and in C In fact most exp erienced C programmers organize their func

tions into mo dules that relate to a single data structure a class and often even use

a naming convention which mimics C for example naming routines StackFull and

StackPush However the features Im ab out to describ e do require a paradigm shift

there is no simple translation from them into a normal C program The b enet will b e that

in some circumstances you will b e able to write generic co de that works with multiple kinds

of ob jects

Nevertheless I would advise a b eginning C programmer against trying to use these

features b ecause you will almost certainly misuse them Its p ossible even easy to write

completely inscrutable co de using inheritance andor templates Although you might nd it

amusing to write co de that is imp ossible for your graders to understand I assure you they

wont nd it amusing at all and will return the favor when they assign grades In industry

a high premium is placed on keeping co de simple and readable Its easy to write new co de

but the real cost comes when you try to keep it working even as you add new features to it

Nachos contains a few examples of the correct use of inheritance and templates but

realize that Nachos do es not use them everywhere In fact if you get confused by this

section dont worry you dont need to use any of these features in order to do the Nachos

assignments I omit a whole bunch of details if you nd yourself making widespread use

of inheritance or templates you should consult a C reference manual for the real sco op

This is meant to b e just enough to get you started and to help you identify when it would

b e appropriate to use these features and thus learn more ab out them

Inheritance

Inheritance captures the idea that certain classes of ob jects are related to each other in useful

ways For example lists and sorted lists have quite similar b ehavior they b oth allow the

user to insert delete and nd elements that are on the list There are two b enets to using

inheritance

You can write generic co de that do esnt care exactly which kind of ob ject it is manip

ulating For example inheritance is widely used in windowing systems Everything on

the screen windows scroll bars titles icons is its own ob ject but they all share a set

of memb er functions in common such as a routine Repaint to redraw the ob ject onto

the screen This way the co de to repaint the entire screen can simply call the Repaint

function on every ob ject on the screen The co de that calls Repaint do esnt need to

know which kinds of ob jects are on the screen as long as each implements Repaint

You can share pieces of an implementation b etween two ob jects For example if

you were to implement b oth lists and sorted lists in C youd probably nd yourself

rep eating co de in b oth places in fact you might b e really tempted to only implement

sorted lists so that you only had to debug one version Inheritance provides a way

to reuse co de b etween nearly similar classes For example given an implementation

of a list class in C you can implement sorted lists by replacing the insert memb er

function the other functions delete isFull print all remain the same

Shared Behavior

Let me use our Stack example to illustrate the rst of these Our Stack implementation ab ove

could have b een implemented with linked lists instead of an array Any co de using a Stack

shouldnt care which implementation is b eing used except that the linked list implementation

cant overow In fact we could also change the array implementation to handle overow

by automatically resizing the array as items are pushed on the stack

To allow the two implementations to co exist we rst dene an abstract Stack containing

just the public memb er functions but no data

class Stack

public

Stack

virtual Stack deallocate the stack

virtual void Pushint value

Push an integer checking for overflow

virtual bool Full Is the stack is full

For g need these even though no data to initialize

StackStack

The Stack denition is called a base class or sometimes a superclass We can then dene

two dierent derived classes sometimes called subclasses which inherit b ehavior from the

base class Of course inheritance is recursive a derived class can in turn b e a base class

for yet another derived class and so on Note that I have prep ended the functions in the

base class is prep ended with the keyword virtual to signify that they can b e redened

by each of the two derived classes The virtual functions are initialized to zero to tell the

compiler that those functions must b e dened by the derived classes

Heres how we could declare the arraybased and listbased implementations of Stack

The syntax public Stack signies that b oth ArrayStack and ListStack are kinds of

Stacks and share the same b ehavior as the base class

class ArrayStack public Stack the same as in Section

public

ArrayStackint sz Constructor initialize variables allocate space

ArrayStack Destructor deallocate space allocated above

void Pushint value Push an integer checking for overflow

bool Full Returns TRUE if the stack is full FALSE otherwise

private

int size The maximum capacity of the stack

int top Index of the lowest unused position

int stack A pointer to an array that holds the contents

class ListStack public Stack

public

ListStack

void Pushint value

bool Full

private

List list list of items pushed on the stack

ListStackListStack

list new List

ListStackListStack

delete list

void ListStackPushint value

listPrependvalue

bool ListStackFull

return FALSE this stack never overflows

The neat concept here is that I can assign p ointers to instances of ListStack or ArrayStack

to a variable of typ e Stack and then use them as if they were of the base typ e

Stack s new ListStack

Stack s new ArrayStack

if stackFull

sPush

if sFull

sPush

delete s

The compiler automatically invokes ListStack op erations for s and ArrayStack op

erations for s this is done by creating a pro cedure table for each ob ject where derived

ob jects override the default entries in the table dened by the base class To the co de ab ove

it invokes the op erations Full Push and delete by indirection through the pro cedure table

so that the co de do esnt need to know which kind of ob ject it is

In this example since I never create an instance of the abstract class Stack I do not need

to implement its functions This might seem a bit strange but rememb er that the derived

classes are the various implementations of Stack and Stack serves only to reect the shared

b ehavior b etween the dierent implementations

Also note that the destructor for Stack is a virtual function but the constructor is

not Clearly when I create an ob ject I have to know which kind of ob ject it is whether

ArrayStack or ListStack The compiler makes sure that no one creates an instance of the

abstract Stack by mistake you cannot instantiate any class whose virtual functions are

not completely dened in other words if any of its functions are set to zero in the class

denition

But when I deallo cate an ob ject I may no longer know its exact typ e In the ab ove co de

I want to call the destructor for the derived ob ject even though the co de only knows that I

am deleting an ob ject of class Stack If the destructor were not virtual then the compiler

would invoke Stacks destructor which is not at all what I want This is an easy mistake to

make I made it in the rst draft of this article if you dont dene a destructor for the

abstract class the compiler will dene one for you implicitly and by the way it wont b e

virtual since you have a real ly unhelpful compiler The result for the ab ove co de would b e

a memory leak and who knows how you would gure that out

Shared Implementation

What ab out sharing co de the other reason for inheritance In C it is p ossible to use

memb er functions of a base class in its derived class You can also share data b etween a

base class and derived classes but this is a bad idea for reasons Ill discuss later

Supp ose that I wanted to add a new memb er function NumberPushed to b oth imple

mentations of Stack The ArrayStack class already keeps count of the numb er of items on

the stack so I could duplicate that co de in ListStack Ideally Id like to b e able to use the

same co de in b oth places With inheritance we can move the counter into the Stack class

and then invoke the base class op erations from the derived class to up date the counter

class Stack

public

virtual Stack deallocate data

virtual void Pushint value Push an integer checking for overflow

virtual bool Full return TRUE if full

int NumPushed how many are currently on the stack

protected

Stack initialize data

private

int numPushed

StackStack

numPushed

void StackPushint value

numPushed

int StackNumPushed

return numPushed

We can then mo dify b oth ArrayStack and ListStack to make use the new b ehavior of

Stack Ill only list one of them here

class ArrayStack public Stack

public

ArrayStackint sz

ArrayStack

void Pushint value

bool Full

private

int size The maximum capacity of the stack

int stack A pointer to an array that holds the contents

ArrayStackArrayStackin t sz Stack

size sz

stack new intsize Lets get an array of integers

void

ArrayStackPushint value

ASSERTFull

stackNumPushed value

StackPush invoke base class to increment numPushed

There are a few things to note

The constructor for ArrayStack needs to invoke the constructor for Stack in order

to initialize numPushed It do es that by adding Stack to the rst line in the

constructor

ArrayStackArrayStackin t sz Stack

The same thing applies to destructors There are sp ecial rules for which get called rst

the constructordestructor for the base class or the constructordestructor for the

derived class All I should say is its a bad idea to rely on whatever the rule is more

generally it is a bad idea to write co de which requires the reader to consult a manual

to tell whether or not the co de works

I intro duced a new keyword protected in the new denition of Stack For a base

class protected signies that those memb er data and functions are accessible to

classes derived recursively from this class but inaccessible to other classes In other

words protected data is public to derived classes and private to everyone else For

example we need Stacks constructor to b e callable by ArrayStack and ListStack

but we dont want anyone else to create instances of Stack Hence we make Stacks

constructor a protected function In this case this is not strictly necessary since the

compiler will complain if anyone tries to create an instance of Stack b ecause Stack still

has an undened virtual functions Push By dening StackStack as protected

you are safe even if someone comes along later and denes StackPush

Note however that I made Stacks data memb er private not protected Although

there is some debate on this p oint as a rule of thumb you should never allow one

class to see directly access the data in another even among classes related by inher

itance Otherwise if you ever change the implementation of the base class you will

have to examine and change all the implementations of the derived classes violating

mo dularity

The interface for a derived class automatically includes all functions dened for its base

class without having to explicitly list them in the derived class Although we didnt

dene NumPushed in ArrayStack we can still call it for those ob jects

ArrayStack s new ArrayStack

ASSERTsNumPushed should be initialized to

Conversely even though we have dened a routine StackPush b ecause it is

declared as virtual if we invoke Push on an ArrayStack ob ject we will get

ArrayStacks version of Push

Stack s new ArrayStack

if sFull ArrayStackFull

sPush ArrayStackPush

StackNumPushed is not virtual That means that it cannot b e redened by

Stacks derived classes Some p eople b elieve that you should mark al l functions in a

base class as virtual that way if you later want to implement a derived class that

redenes a function you dont have to mo dify the base class to do so

Memb er functions in a derived class can explicitly invoke public or protected functions

in the base class by the full name of the function BaseFunction as in

void ArrayStackPushint value

StackPush invoke base class to increment numPushed

Of course if we just called Push here without prep ending Stack the compiler

would think we were referring to ArrayStacks Push and so that would recurse

which is not exactly what we had in mind here

Whew Inheritance in C involves lots and lots of details But its real downside is

that it tends to spread implementation details across multiple les if you have a deep

inheritance tree it can take some serious digging to gure out what co de actually executes

when a memb er function is invoked

So the question to ask yourself b efore using inheritance is whats your goal Is it to

write your programs with the fewest numb er of characters p ossible If so inheritance is

really useful but so is changing all of your function and variable names to b e one letter long

a b c and once you run out of lower case ones start using upp er case then two

character variable names XX XY XZ Ya Im joking here Needless to say it is really

easy to write unreadable co de using inheritance

So when is it a go o d idea to use inheritance and when should it b e avoided My rule

of thumb is to only use it for representing shared behavior b etween ob jects and to never

use it for representing shared implementation With C you can use inheritance for b oth

concepts but only the rst will lead to truly simpler implementations

To illustrate the dierence b etween shared b ehavior and shared implementation supp ose

you had a whole bunch of dierent kinds of ob jects that you needed to put on lists For

example almost everything in an op erating system go es on a list of some sort buers

threads users terminals etc

A very common approach to this problem particularly among p eople new to ob ject

oriented programming is to make every ob ject inherit from a single base class Object which

contains the forward and backward p ointers for the list But what if some ob ject needs

to go on multiple lists The whole scheme breaks down and its b ecause we tried to use

inheritance to share implementation the co de for the forward and backward p ointers instead

of to share b ehavior A much cleaner although slightly slower approach would b e to dene

a list implementation that allo cated forwardbackward p ointers for each ob ject that gets put

on a list

In sum if two classes share at least some of the same memb er function signatures that

is the same b ehavior and if theres co de that only relies on the shared b ehavior then there

may b e a b enet to using inheritance In Nachos lo cks dont inherit from semaphores even

though lo cks are implemented using semaphores The op erations on semaphores and lo cks

are dierent Instead inheritance is only used for various kinds of lists sorted keyed etc

and for dierent implementations of the physical disk abstraction to reect whether the disk

has a track buer etc A disk is used the same way whether or not it has a track buer the

only dierence is in its p erformance characteristics

Templates

Templates are another useful but dangerous concept in C With templates you can

parameterize a class denition with a type to allow you to write generic typ eindep endent

co de For example our Stack implementation ab ove only worked for pushing and p opping

integers what if we wanted a stack of characters or oats or p ointers or some arbitrary

data structure

In C this is pretty easy to do using templates

template class T

class Stack

public

Stackint sz Constructor initialize variables allocate space

Stack Destructor deallocate space allocated above

void PushT value Push an integer checking for overflow

bool Full Returns TRUE if the stack is full FALSE otherwise

private

int size The maximum capacity of the stack

int top Index of the lowest unused position

T stack A pointer to an array that holds the contents

To dene a template we prep end the keyword template to the class denition and we

put the parameterized typ e for the template in angle brackets If we need to parameterize

the implementation with two or more typ es it works just like an argument list template

class T class S We can use the typ e parameters elsewhere in the denition just like

they were normal typ es

When we provide the implementation for each of the memb er functions in the class we

also have to declare them as templates and again once we do that we can use the typ e

parameters just like normal typ es

template version of StackStack

template class T

StackTStackint sz

size sz

top

stack new Tsize Lets get an array of type T

template version of StackPush

template class T

void

StackTPushT value

ASSERTFull

stacktop value

Creating an ob ject of a template class is similar to creating a normal ob ject

void

test

Stackint s

Stackchar s new Stackchar

sPush

sPushz

delete s

Everything op erates as if we dened two classes one called Stackint a stack of

integers and one called Stackchar a stack of characters s b ehaves just like an instance

of the rst s b ehaves just like an instance of the second In fact that is exactly how

templates are typically implemented you get a complete copy of the co de for the template

for each dierent instantiated typ e In the ab ove example wed get one copy of the co de for

ints and one copy for chars

So whats wrong with templates Youve all b een taught to make your co de mo dular so

that it can b e reusable so everything should b e a template right Wrong

The principal problem with templates is that they can b e very dicult to debug tem

plates are easy to use if they work but nding a bug in them can b e dicult In part this

is b ecause current generation C debuggers dont really understand templates very well

Nevertheless it is easier to debug a template than two nearly identical implementations that

dier only in their typ es

So the b est advice is dont make a class into a template unless there really is a near

term use for the template And if you do need to implement a template implement and

debug a nontemplate version rst Once that is working it wont b e hard to convert it to

a template Then all you have to worry ab out co de explosion eg your programs ob ject

co de is now megabytes b ecause of the copies of the hash tablelist routines one for

each kind of thing you want to put in a hash tablelist Rememb er you have an unhelpful

compiler

Features To Avoid Like the Plague

Despite the length of this note there are numerous features in C that I havent explained

Im sure each feature has its advo cates but despite programming in C and C for over

years I havent found a comp elling reason to use them in any co de that Ive written outside

of a programming language class

Indeed there is a comp elling reason to avoid using these features they are easy to misuse

resulting in programs that are harder to read and understand instead of easier to understand

In most cases the features are also redundant there are other ways of accomplishing the

same end Why have two ways of doing the same thing Why not stick with the simpler

one

I do not use any of the following features in Nachos If you use them caveat hacker

Multiple inheritance It is p ossible in C to dene a class as inheriting b ehavior

from multiple classes for instance a dog is b oth an animal and a furry thing But if

programs using single inheritance can b e dicult to untangle programs with multiple

inheritance can get really confusing

References Reference variables are rather hard to understand in general they play

the same role as p ointers with slightly dierent syntax unfortunately Im not jok

ing Their most common use is to declare some parameters to a function as reference

parameters as in Pascal A callbyreference parameter can b e mo died by the calling

function without the callee having to pass a p ointer The eect is that parameters

lo ok to the caller like they are called by value and therefore cant change but in

fact can b e transparently mo died by the called function Obviously this can b e a

source of obscure bugs not to mention that the semantics of references in C are in

general not obvious

Op erator overloading C lets you redene the meanings of the op erators such as

and for class ob jects This is dangerous at b est exactly which implementation

of do es this refer to and when used in nonintuitive ways a source of great

confusion made worse by the fact that C do es implicit typ e conversion which can

aect which op erator is invoked Unfortunately Cs IO facilities make heavy use

of op erator overloading and references so you cant completely escap e them but think

twice b efore you redene to mean concatenate these two strings

Function overloading You can also dene dierent functions in a class with the

same name but dierent argument typ es This is also dangerous since its easy to

slip up and get the unintended version and we never use it We will also avoid using

default arguments for the same reason Note that it can b e a go o d idea to use the

same name for functions in dierent classes provided they use the same arguments

and b ehave the same way a go o d example of this is that most Nachos ob jects have

a Print metho d

Standard template library An ANSI standard has emerged for a library of rou

tines implementing such things as lists hash tables etc called the standard template

library Using such a library should make programming much simpler if the data struc

ture you need is already provided in the library Alas the standard template library

pushes the envelop e of legal C and so virtually no compilers including g can

supp ort it to day Not to mention that it uses big surprise references op erator

overloading and function overloading

Exceptions There are two ways to return an error from a pro cedure One is simple

just dene the pro cedure to return an error co de if it isnt able to do its job For

example the standard library routine malloc returns NULL if there is no available

memory However lots of programmers are lazy and dont check error co des So

whats the solution You might think it would b e to get programmers who arent lazy

but no the C solution is to add a programming language construct A pro cedure

can return an error by raising an exception which eectively causes a goto back up

the execution stack to the last place the programmer put an exception handler You

would think this is to o bizarre to b e true but unfortunately Im not making this up

While Im at it there are a numb er of features of C that you also should avoid b ecause

they lead to bugs and make your co de less easy to understand See Maguires Writing Solid

Co de for a more complete discussion of this issue All of these features are legal C whats

legal isnt necessarily go o d

Pointer arithmetic Runaway p ointers are a principal source of hardtond bugs in C

programs b ecause the symptom of this happ ening can b e mangled data structures in

a completely dierent part of the program Dep ending on exactly which ob jects are

allo cated on the heap in which order p ointer bugs can app ear and disapp ear seemingly

at random For example printf sometimes allo cates memory on the heap which can

change the addresses returned by all future calls to new Thus adding a printf can

change things so that a p ointer which used to by happ enstance mangle a critical data

structure such as the middle of a threads execution stack now overwrites memory

that may not even b e used

The b est way to avoid runaway p ointers is no surprise to b e very careful when using

p ointers Instead of iterating through an array with p ointer arithmetic use a separate

index variable and assert that the index is never larger than the size of the array

Optimizing compilers have gotten very go o d so that the generated machine co de is

likely to b e the same in either case

Even if you dont use p ointer arithmetic its still easy easy is bad in this context to

have an obyone errror that causes your program to step b eyond the end of an array

How do you x this Dene a class to contain the array and its length b efore allowing

any access to the array you can then check whether the access is legal or in error

Casts from integers to p ointers and back Another source of runaway p ointers is that

C and C allow you to convert integers to p ointers and back again Needless to say

using a random integer value as a p ointer is likely to result in unpredictable symptoms

that will b e very hard to track down

In addition on some bit machines such as the Alpha it is no longer the case that

the size of an integer is the same as the the size of a p ointer If you cast b etween

p ointers and integers you are also writing highly nonp ortable co de

Using bit shift in place of a multiply or divide This is a clarity issue If you are doing

arithmetic use arithmetic op erators if you are doing bit manipulation use bitwise

op erators If I am trying to multiply by which is easier to understand x

or x In the s when C was b eing develop ed the former would yield more

ecient machine co de but to days compilers generate the same co de in b oth cases so

readability should b e your primary concern

Assignment inside conditional Many programmers have the attitude that simplicity

equals saving as many keystrokes as p ossible The result can b e to hide bugs that

would otherwise b e obvious For example

if x y

Was the intent really x y After all its pretty easy to mistakenly leave o the

extra equals sign By never using assignment within a conditional you can tell by co de

insp ection whether youve made a mistake

Using define when you could use enum When a variable can hold one of a small

numb er of values the original C practice was to use define to set up symb olic names

for each of the values enum do es this in a typ esafe way it allows the compiler to

verify that the variable is only assigned one of the enumerated values and none other

Again the advantage is to eliminate a class of errors from your program making it

quicker to debug

Style Guidelines

Even if you follow the approach Ive outlined ab ove it is still as easy to write unreadable and

undebuggable co de in C as it is in C and p erhaps easier given the more p owerful features

the language provides For the Nachos pro ject and in general we suggest you adhere to the

following guidelines and tell us if you catch us breaking them

Words in a name are separated SmallTalkstyle ie capital letters at the start of each

new word All class names and memb er function names b egin with a capital letter

except for memb er functions of the form getSomething and setSomething where

Something is a data element of the class ie accessor functions Note that you would

want to provide such functions only when the data should b e visible to the outside

world but you want to force all accesses to go through one function This is often a

go o d idea since you might at some later time decide to compute the data instead of

storing it for example

All global functions should b e capitalized except for main and library functions which

are kept lowercase for historical reasons

Minimize the use of global variables If you nd yourself using a lot of them try and

group some together in a class in a natural way or pass them as arguments to the

functions that need them if you can

Minimize the use of global functions as opp osed to memb er functions If you write a

function that op erates on some ob ject consider making it a memb er function of that

ob ject

For every class or set of related classes create a separate h le and cc le The h le

acts as the interface to the class and the cc le acts as the implementation a given

cc le should include its resp ective h le If using a particular h le requires

another h le to b e included eg synchh needs class denitions from threadh

you should include the dep endency in the h le so that the user of your class do esnt

have to track down all the dep endencies himself To protect against multiple inclusion

bracket each h le with something like

ifndef STACKH

define STACKH

class Stack

endif

Sometimes this will not b e enough and you will have a circular dep endency For

example you might have a h le that uses a denition from one h le but also

denes something needed by that h le In this case you will have to do something

adho c One thing to realize is that you dont always have to completely dene a class

b efore it is used If you only use a p ointer to class Stack and do not access any memb er

functions or data from the class you can write in lieu of including stackh

class Stack

This will tell the compiler all it needs to know to deal with the p ointer In a few cases

this wont work and you will have to move stu around or alter your denitions

Use ASSERT statements lib erally to check that your program is b ehaving prop erly An

assertion is a condition that if FALSE signies that there is a bug in the program

ASSERT tests an expression and ab orts if the condition is false We used ASSERT ab ove

in StackPush to check that the stack wasnt full The idea is to catch errors

as early as p ossible when they are easier to lo cate instead of waiting until there is

a uservisible symptom of the error such as a segmentation fault after memory has

b een trashed by a rogue p ointer

Assertions are particularly useful at the b eginnings and ends of pro cedures to check

that the pro cedure was called with the right arguments and that the pro cedure did

what it is supp osed to For example at the b eginning of ListInsert you could assert

that the item b eing inserted isnt already on the list and at the end of the pro cedure

you could assert that the item is now on the list

If sp eed is a concern ASSERTs can b e dened to make the check in the debug version

of your program and to b e a noop in the pro duction version But many p eople run

with ASSERTs enabled even in pro duction

Write a mo dule test for every mo dule in your program Many programmers have the

notion that testing co de means running the entire program on some sample input if

it do esnt crash that means its working right Wrong You have no way of knowing

how much co de was exercised for the test Let me urge you to b e metho dical ab out

testing Before you put a new mo dule into a bigger system make sure the mo dule

works as advertised by testing it standalone If you do this for every mo dule then

when you put the mo dules together instead of hoping that everything will work you

will know it will work

Perhaps more imp ortantly mo dule tests provide an opp ortunity to nd as many bugs

as p ossible in a lo calized context Which is easier nding a bug in a line program

or in a line program

Compiling and Debugging

The Makeles we will give you works only with the GNU version of make called gmake

You may want to put alias make gmake in your cshrc le

You should use gdb to debug your program rather than dbx Dbx do esnt know how to

decipher C names so you will see function names like RunSchedulerPThread

On the other hand in GDB but not DBX when you do a stack backtrace when in a

forked thread in homework after printing out the correct frames at the top of the stack

the debugger will sometimes go into a lo op printing the lowermost frame ThreadRoot and

you have to typ e controlC when it says more If you understand assembly language and

can x this please let me know

Example A Stack of Integers

Weve provided the complete working co de for the stack example You should read through

it and play around with it to make sure you understand the features of C describ ed in

this pap er

To compile the simple stack test typ e make all this will compile the simple stack test

stackcc the inherited stack test inheritstackcc and the template version of stacks

templatestackcc

Epilogue

Ive argued in this note that you should avoid using certain C and C features But youre

probably thinking I must b e leaving something out if someone put the feature in the

language there must b e a go o d reason right I b elieve that every programmer should strive

to write co de whose b ehavior would b e immediately obvious to a reader if you nd yourself

writing co de that would require someone reading the co de to thumb through a manual in

order to understand it you are almost certainly b eing way to o subtle Theres probably a

much simpler and more obvious way to accomplish the same end Mayb e the co de will b e a

little longer that way but in the real world its whether the co de works and how simple it

is for someone else to mo dify that matters a whole lot more than how many characters you

had to typ e

A nal thought to rememb er

There are two ways of constructing a software design one way is to make it so

simple that there are obviously no deciencies and the other way is to make it so

complicated that there are no obvious deciencies

C A R Hoare The Emp erors Old Clothes CACM Feb