Download A Historical Overview of Object-Oriented Programming Languages: From Simula 67 to C++ - Pr and more Assignments Programming Languages in PDF only on Docsity!
Prof. Su ECS 140A Lecture 9 1
Programming Languages
ECS 140A
13:40-15:00 Tu/Th
55 Roessler
Prof. Su ECS 140A Lecture 9 2
Announcements/reminders
- HW3 due May 7th
- Midterm on May 12th
Prof. Su ECS 140A Lecture 9 3
Brief History
- Simula 67 (Dahl, Nygaard)
- First OO language, extends Algol 60
- Added the notion of an “object”
- Inspired other OO languages (e.g., Smalltalk, C++)
- Smalltalk (Alan Kay)
- Major language that popularized objects
- Developed at Xerox PARC
- Smalltalk-76, Smalltalk-80 were important versions
- Object metaphor extended and refined
- Everything is an object, even a class
- All operations are “messages to objects”
- Very flexible and powerful language
Prof. Su ECS 140A Lecture 9 4
Brief History (cont.)
- C++ (Bjarne Stroustrup)
- Early extension to C based primarily on Simula
- Called “C with classes” in early 1980’s
- Features were added incrementally
- Classes, templates, exceptions, multiple inheritance, …
- Java (James Gosling and others at Sun)
- Internet applications
- Design goals
- Portability
- Reliability and Safety
- Simplicity and familiarity
- Efficiency
Prof. Su ECS 140A Lecture 9 5
Our Plan
(See book for information on Smalltalk)
Prof. Su ECS 140A Lecture 9 6
C++
Prof. Su ECS 140A Lecture 9 10
Significant constraints
- C has specific machine model
- Access to underlying architecture
- No garbage collection
- Consistent with goal of efficiency
- Need to manage object memory explicitly
- Local variables stored in activation records
- Objects treated as generalization of structs, so
some objects may be allocated on stack
- Stack/heap difference is visible to programmer
Prof. Su ECS 140A Lecture 9 11
Overview of C++
- Additions and changes not related to objects
- type bool
- pass-by-reference
- user-defined overloading
- function templates
- …
Prof. Su ECS 140A Lecture 9 12
C++ Object System
- Object-oriented features
- Classes
- Objects, with dynamic lookup of virtual functions
- Inheritance
- Single and multiple inheritance
- Public and private base classes
- Subtyping
- Tied to inheritance mechanism
- Encapsulation
Prof. Su ECS 140A Lecture 9 13
Some good decisions
- Public, private, protected levels of visibility
- Public: visible everywhere
- Protected: within class and subclass declarations
- Private: visible only in class where declared
- Friend functions and classes
- Careful attention to visibility and data abstraction
- Allow inheritance without subtyping
- Better control of subtyping than without private
base classes
Prof. Su ECS 140A Lecture 9 14
Some problem areas
- Casts
- Sometimes no-op, sometimes not (e.g., multiple inheritance)
- Lack of garbage collection
- Memory management is error prone
- Constructors, destructors are helpful though
- Objects allocated on stack
- Better efficiency, interaction with exceptions
- BUT assignment works badly, possible dangling ptrs
- Overloading
- Too many code selection mechanisms?
- Multiple inheritance
- Efforts at efficiency lead to complicated behavior
Prof. Su ECS 140A Lecture 9 15
Sample class: one-dimen. points
class Pt { public: Pt(int xv); Pt(Pt* pv); int getX(); virtual void move(int dx); protected: void setX(int xv); private: int x; };
Overloaded constructor
Public read access to private data Virtual function
Protected write access
Private member data
Prof. Su ECS 140A Lecture 9 19
Looking up methods
blue
Point object
ColorPoint object
x
vptr
x
vptr
c
Point vtable
ColorPoint vtable
Code for move
Code for move
Code for darken
Pt *p = new Pt(3);
p->move(2); // (*(p->vptr[0]))(p,2)
Prof. Su ECS 140A Lecture 9 20
Looking up methods, part 2
blue
Point object
ColorPoint object
x
vptr
x
vptr
c
Point vtable
ColorPoint vtable
Code for move
Code for move
Code for darken
Pt *cp = new ColorPt(5,blue);
cp->move(2); // (*(cp->vptr[0]))(cp,2)
Prof. Su ECS 140A Lecture 9 21
Calls to virtual functions
- One member function may call another class A { public: virtual int f (int x); virtual int g(int y); }; int A::f(int x) { … g(i) …;} int A::g(int y) { … f(j) …;}
- How does body of f call the right g?
- If g is redefined in derived class B, then inherited f must call B::g
Prof. Su ECS 140A Lecture 9 22
“This” pointer
- Code is compiled so that member function
takes “object itself” as first argument
Code int A::f(int x) { … g(i) …;}
compiled as int A::f(A *this, int x) { … this->g(i) …;}
- “this” pointer may be used in member function
- Can be used to return pointer to object itself, pass
pointer to object itself to another function, ...
Prof. Su ECS 140A Lecture 9 23
Non-virtual functions
- How is code for non-virtual function found?
- Same way as ordinary “non-member” functions:
- Compiler generates function code and assigns address
- Address of code is placed in symbol table
- At call site, address is taken from symbol table and placed in compiled code
- But some special scoping rules for classes
- Overloading
- Remember: overloading is resolved at compile time
- This is different from run-time lookup of virtual function
Prof. Su ECS 140A Lecture 9 24
Scope rules in C++
- Scope qualifiers
- binary :: operator, ->, and.
- class::member, ptr->member, object.member
- A name outside a function or class,
- not prefixed by unary :: and not qualified refers to
global object, function, enumerator or type.
- A name after X::, ptr-> or obj.
- where we assume ptr is pointer to class X and obj is
an object of class X
- refers to a member of class X or a base class of X
Prof. Su ECS 140A Lecture 9 28
Independent classes not subtypes
class Point { public: int getX(); void move(int); protected: ... private: ... };
class ColorPoint { public: int getX(); void move(int); int getColor(); void darken(int); protected: ... private: ... };
- C++ does not treat ColorPoint <: Point as written
- Need public inheritance ColorPoint : public Point
- Why?
Prof. Su ECS 140A Lecture 9 29
Why C++ design?
- Client code depends only on public interface
- In principle, if ColorPoint interface contains Point interface, then any client could use ColorPoint in place of point
- However -- offset in virtual function table may differ
- Lose implementation efficiency (like Smalltalk)
- Without link to inheritance
- subtyping leads to loss of implementation efficiency
- Also encapsulation issue:
- Subtyping based on inheritance is preserved under modifications to base class …
Prof. Su ECS 140A Lecture 9 30
Function subtyping
- Subtyping principle
- A <: B if an A expression can be safely used in any
context where a B expression is required
- Subtyping for function results
- If A <: B, then C -> A <: C -> B
- Subtyping for function arguments
- If A <: B, then B -> C <: A -> C
- Terminology
- Covariance: A <: B implies F(A) <: F(B)
- Contravariance: A <: B implies F(B) <: F(A)
Prof. Su ECS 140A Lecture 9 31
Examples
C++ compilers recognize limited forms of function subtyping
circle -> shape
circle -> circle shape -> shape
shape -> circle
Prof. Su ECS 140A Lecture 9 32
Subtyping with functions
- In principle: can have ColorPoint <: Point
- In practice: some compilers allow, others have not This is covariant case; contravariance is another story
class Point { public: int getX(); virtual Point *move(int); protected: ... private: ... };
class ColorPoint: public Point { public: int getX(); int getColor(); ColorPoint * move(int); void darken(int); protected: ... private: ... };
Inherited, but repeated here for clarity
Prof. Su ECS 140A Lecture 9 33
Abstract Classes
- Abstract class:
- A class without complete implementation
- Declare by =0 (what a great syntax!)
- Useful because it can have derived classes Since subtyping follows inheritance in C++, use abstract classes to build subtype hierarchies.
- Establishes layout of virtual function table (vtable)
- Example
- Geometry classes
- Shape is abstract supertype of circle, rectangle, ...
Prof. Su ECS 140A Lecture 9 37
Repair to previous example
- Rewrite class C to call A::f explicitly class C : public A, public B { public: void virtual f( ) { A::f( ); // Call A::f(), not B::f(); }
- Reasonable solution
- This eliminates ambiguity
- Preserves dependence on A
- Changes to A::f will change C::f
Prof. Su ECS 140A Lecture 9 38
vtable for Multiple Inheritance
class A { public: int x; virtual void f(); }; class B { public: int y; virtual void g(); virtual void f(); };
class C: public A, public B { public: int z; virtual void f(); };
C *pc = new C; B *pb = pc; A *pa = pc; Three pointers to same object, but different static types.
Prof. Su ECS 140A Lecture 9 39
Object and classes
- Offset in vtbl is used in call to pb->f, since C::f may refer to A data that is above the pointer pb
- Call to pc->g can proceed through C-as-B vtbl
C object
C
A B
vptr
B data
vptr
A data
C data
B object
A object
& C::f 0
C-as-A vtbl
C-as-B vtbl
& B::g 0
& C::f
pa, pc
pb
Prof. Su ECS 140A Lecture 9 40
Multiple Inheritance “Diamond”
- Is interface or implementation inherited twice?
- What if definitions conflict?
Window (D)
Text Window (A) Graphics Window (B)
Text, Graphics Window (C)
Prof. Su ECS 140A Lecture 9 41
Diamond inheritance in C++
- Standard base classes
- D members appear twice in C
- Virtual base classes class A : public virtual D { … }
- Avoid duplication of base class members
- Require additional pointers so that D part of A, B parts of object can be shared
C
A B
D
- C++ multiple inheritance is complicated in part
because of desire to maintain efficient lookup
A part
D part
C part
B part
Prof. Su ECS 140A Lecture 9 42
C++ Summary
- Objects
- Created by classes
- Contain member data and pointer to class
- Classes: virtual function table
- Inheritance
- Public and private base classes, multiple inheritance
- Subtyping: Occurs with public base classes only
- Encapsulation
- member can be declared public, private, protected
- object initialization partly enforced
