1. Lists
CMSC 202, Version 4/02

2. Review: ADTs A concept, not an implementation
A set of (homogeneous) objects together with a set of operations on those objects
No mention of how the operations are implemented
No rules tell which operations are required
A design decision
CMSC 202, Version 4/02

3. Review: ADTs (con’t)
From the outside, the user sees only a collection of operations that together define the behavior of the abstraction.
The user also sees how to use the operations (via the operation interfaces).
On the other side, the programmer implementing the abstraction sees the data variables that are used to maintain the state.
CMSC 202, Version 4/02

4. A List ADT
A list is a dynamic, homogeneous tuple (set of ordered items)
A1, A2, A3, …, An
where Ai is the ith item in the list.
The position of item Ai is i. Positions range from 1 to n, inclusive.
The size of a list is n.
A list of containing no items is called an empty list.
dynamic means the list can change over time
homogeneous means the elements are all of the same type
ordered means that A1+1 follows (or succeeds) Ai and Ai-1 precedes Ai
CMSC 202, Version 4/02

5. Typical List Operations
Construct a new empty list
Construct a new list as a copy of an existing list
Destroy the list
Make the list empty
Insert an element into the list
Remove an element from the list
Locate the position of an item in the list
Find the value of the nth item in the list
Assign one list to another
Determine if the list is full
Determine if the list is empty
Print the list
CMSC 202, Version 4/02

6. Design Considerations
How many items will the list be able to hold?
Some maximum number
An “infinite” number (how will this be handled?)
Will duplicate items be allowed? If so, how will this affect insert, delete, print, etc.?
CMSC 202, Version 4/02

7. Example ADT: List of Integers
All lists work the same way, regardless of the type of data stored in the list. We’ll use a list of integers for our discussion.
We will follow this procedure:
Outline assumptions that we will make about a list
Decide on the list operations
Translate the list operations into their C++ interfaces, deciding which will be public, private, and friends
Be careful not to make any assumptions about how the list will actually be represented (e.g., an array, a linked list).
CMSC 202, Version 4/02

8. Design Assumptions: The list will be a list of integers.
Notice that we did not say “int’s”. How the integers are implemented will be decided later (ints, strings, or some other representation).
The list can hold a maximum of 1,000 items.
The list can be empty.
Duplicate items will not be allowed.
CMSC 202, Version 4/02

9. Design (con’t) Operations: Construct a new empty list
Construct a new list as a copy of an existing list
Destroy the list
Assign one list to another
Determine if the list is full
Determine if the list is empty
Make the list empty
Find the value of the nth item in the list
Locate the position of an item in the list
Insert an element into the list
Remove an element from the list
Print the list
CMSC 202, Version 4/02

10. Operation Interfaces Construct a new empty list // default constructor
IntList::IntList(int initialSize = 100);
Construct a new list as a copy of an existing list
// copy constructor
IntList::IntList(const IntList& rhs);
CMSC 202, Version 4/02

11. Operation Interfaces (con’t)
Destroy the list
// destructor
IntList::~IntList( );
Make the list empty
void IntList::makeEmpty( );
CMSC 202, Version 4/02

12. Operation Interfaces (con’t)
Check for an empty list
Design decision:
Make a private member function
bool IntList::isEmpty ( ) const;
Check for a full list
Design:
bool IntList::isFull ( ) const;
CMSC 202, Version 4/02

13. Operation Interfaces (con’t)
Assign one list to another
IntList& IntList::operator= (const IntList&);
CMSC 202, Version 4/02

14. Operation Interfaces (con’t)
Insert an item into the list
Design decision:
If the item is already in the list, return 0 and do not insert the item
int IntList::insert(int x);
Design observation:
Notice that the data, not a “package” (such as a node with a next pointer) is sent into the function.
CMSC 202, Version 4/02

15. Operation Interfaces (con’t)
Remove an item at a given position from the list
Design Decision:
If the item is not in the list, return 0;
int IntList::remove(int x);
CMSC 202, Version 4/02

16. Operation Interfaces (con’t)
Locate the position of an item in the list
Design decision:
If the item is not in the list, return 0
int IntList::findPosition(int x) const;
CMSC 202, Version 4/02

17. Operation Interfaces (con’t)
Return the item in the nth position
Design Decision:
If the position is out of range, return 0.
int IntList::elementAt (int position) const;
CMSC 202, Version 4/02

18. Operation Interfaces (con’t)
Print the list
Design decision:
Overload the << operator rather than create a named function
Make a friend of the IntList class
// overloaded << operator
ostream& operator<< (ostream&, const IntList &);
CMSC 202, Version 4/02

19. IntList Interface class IntList {
friend ostream& operator<<(ostream& out, const IntList &L); public:
IntList (int size = 100);
IntList (const IntList&);
~IntList ( );
IntList& operator= (const IntList &); void makeEmpty ( );
int elementAt (int position) const;
int findPosition (int x) const;
int insert (int x);
int remove (int x);
private:
bool isFull ( ) const;
bool isEmpty ( ) const; };
CMSC 202, Version 4/02

20. Using IntList IntList L1; // a list with room for 100 integers int x;
L1.insert (7);
L1.insert (42);
x = L1.elementAt( 1 );
cout << L1 << endl;
L1.remove (22);
if (! L1.isEmpty ( ) )
L1. makeEmpty ( ) ;
CMSC 202, Version 4/02

21. Using IntList (cont’d)
Observations:
Client (application) code can only use public methods and friend functions provided by IntList.
We can now choose any data representation for the IntList that we want to with no impact on the client code.
If the representation changes later, there is no impact on the client code (except for possible recompilation).
CMSC 202, Version 4/02

22. Using IntList (cont’d)
We deliver the interface (.H) to the customer in source code form.
It doesn’t matter if the application programmer sees the representation. He/she still has no direct access to an IntList.
The representation (and all private class members) may be hidden via the use of a proxy class.
CMSC 202, Version 4/02

23. IntList Implementation
Choices:
array
linked list
Regardless of the choice, we need to store the following information:
maximum capacity of the list
actual size of the list
the list items
CMSC 202, Version 4/02

24. Array Implementation class IntList { friend . . . public: . . .
private:
// private member functions here
int capacity;
int size;
int *theArray; };
CMSC 202, Version 4/02

25. Linked List Implementation I
struct Node { // using a struct as a node
int data;
Node* next; };
class IntList {
friend . . .
public:
private:
// private member functions here
int capacity;
int size;
Node *theList; };
CMSC 202, Version 4/02

26. Linked List Implementation II
class Node { // using an object as a node
friend class IntList; // makes life easier
public:
Node(int = 0);
private:
int data;
Node* next; };
class IntList {
// same as before
private: // same as before
// private member functions here
int capacity;
int size;
Node *theList; };
CMSC 202, Version 4/02

27. Array vs. Linked List What are my memory requirements?
What are my response time requirements?
What is the asymptotic performance of each method for each implementation?
Will the list be used by other applications for other types of data?
How easy is it to generalize the list implementation (e.g., using templates)?
CMSC 202, Version 4/02

28. Generalized Linked List
template <class NODETYPE> class List; // forward
// declaration
template <class NODETYPE>
class Node {
friend class List<NODETYPE>; // no longer called IntList!
public:
Node(const NODETYPE& );
NODETYPE getData( ) const;
private:
NODETYPE data;
Node<NODETYPE>* next; };
CMSC 202, Version 4/02

29. Generalized Linked List (con’t)
template <class NODETYPE>
class List { // No longer called IntList!
public:
void insert(const NODETYPE &data); // sample method
. . .
void print( ) const; // rather than overloading <<
private:
// private member functions here
int capacity;
int size;
Node<NODETYPE> *theList; };
CMSC 202, Version 4/02

30. Generalized Linked List (con’t)
#include “list.H”
int main( ) {
List<int> integerList;
List<SomeClass> someList;
. . .
return 0; }
(See your text for more details on the generalized linked list implementation.)
CMSC 202, Version 4/02