Professional Documents
Culture Documents
University of Bristol, UK
Introduction to C++
Lecturer:
Dr Tilo Burghardt
( mailto: tilo@cs.bris.ac.uk )
Web Materials:
http://www.cs.bris.ac.uk/Teaching/Resources/COMS12800
LECTURE 1
On Objects and Objectives:
A JOURNEY
FROM PROGRAMS
TO SOFTWARE
Tilo Burghardt
Tilo Burghardt
IN THIS COURSE
How can we change our programming approach better to
manage the requirements & challenges of more complex
software?
Tilo Burghardt
Tilo Burghardt
Apple II (1977)
Tilo Burghardt
Mobiles Devices
Introduction
Introduction
stateless
functions
instructions
main
program
procedure
module
unstructured
(e.g. ASSEMBLY 1950s)
Tilo Burghardt
Historical Note
ASSEMBLY
FORTRAN 1956
ALGOL 1960
CPL 1963
BCPL 1966
LISP 1960
Smalltalk1980
Objective C 1986
Algol W 1966
Pascal 1970
Delphi 1995
B 1969
C 1972
C++ 1983
C++11 2011
John Backus
(Fortran-1956)
Tilo Burghardt
XC 2009
.
Java 1995
Martin Richards
(BCPL-1966)
C# 2001
Ken Thompson
(B-1969 ,C-1972)
Dennis Richie
(C-1972)
Bjarne Stroustrup
(C++ -1983)
Historical Note
Tilo Burghardt
long-standing ubiquity
object-oriented paradigm
high performance
timely evolutions/extensions
- (e.g. C++11, C++11AMP etc)
Key Concepts
stateless
functions
main
main
stateful
objects
with
identity
unstructured
procedural & modular object oriented (OO)
(e.g. ASSEMBLY)
(e.g. C, PASCAL,...)
(e.g. C++, Java, Delphi...)
Tilo Burghardt
Key Concept
{
// create an object of type Card
// and initialise its properties
Card myCard;
INSTANTIATION:
class Card is a type and the programmer
can declare variables of that type, i.e. actual
objects or instances (such as myCard)
during declaration all the memory needed
for the properties of the object is allocated
(like malloc in C) and then a special method,
the constructor, is called for initialising the
properties of the object created (such as
setting the initial balance of the card etc)
myCard.showId();
myCard.payLunch();
myCard.showBalance();
myCard.payLunch();
METHOD CALLS:
ask the object myCard to do something,
i.e. call the procedure printId from the
context of myCard
DESTRUCTION:
once myCard goes out of scope, a special
}
method, the destructor, is called to cleanup
the memory allocated throughout myCards
lifetime,
the object
is lost| forever
Tilo Burghardt | 2011-12 | Introduction to C++ COMS12800 | Computer
Science then
| University
of Bristol
Lecture 1 | 13
return EXIT_SUCCESS;
Key Concept
Card myCard001;
Card myCard002;
Card myCard003;
return EXIT_SUCCESS;
}
Tilo Burghardt
Key Concept
defining a class
and giving it the
name Card
//constructor
//destructor
//print id
//print balance
//reduce balance
} Card;
Tilo Burghardt
//balance on card
the methods of
an object,
essentially a
collection of
procedures
the properties of
an object,
essentially a
collection of
fields similar to
a struct in C
Key Concept
defining a constructor
to initialise the properties
//constructor
Card::Card()
{
id = 0;
balance = 100;
};
//destructor
Card::~Card()
{};
defining an empty
destructornothing to
cleanup since nothing
is created in constructor
Defining the behaviour
of a card by providing
procedures or functions
that operate on the
properties (e.g. print
values to the screen,
change values etc)
Tilo Burghardt
#include <iostream>
#include Card.h"
Card::Card()
{
id = 0;
balance = 100;
};
#include <iostream>
#include Card.h
int main(void)
{
{
Card myCard;
myCard.showId();
myCard.payLunch();
Card::~Card() {};
void Card::showId()
{
std::cout << "Card ID: " <<
id << std::endl;
}
myCard.showBalance();
myCard.payLunch();
}
return EXIT_SUCCESS;
} Card;
void Card::showBalance()
{
std::cout << "Balance is: " <<
balance << std::endl;
}
void Card::payLunch()
{
balance--;
}
Development Environment:
Visual Studio
Key Concept
type / structure
with fields allowing you to define variables
(properties) and procedures (methods)
context /namespace
providing implicit locality to its methods
(e.g. dot-notation myCard.payLunch())
no name clashes between different classes
//constructor
//destructor
//print id
//print balance
//reduce balance
//balance on card
} Card;
| 19
Some Principles of
Good Object Oriented Design (OOD)
Flexibility
you can easily adapt code to address new problems
Reusability
you avoid coding the same behaviour over and over again
Maintainability
you can easily add features
Low Coupling
objects are fairly independent so you can work in teams,
sharing
Scalability
small classes can be combined into complex programs
without loosing oversight and control
Tilo Burghardt
Basics of Inheritance
(Evolution & Specialisation for Classes)
Tilo Burghardt