Lists

1
Lists
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

3
Review ADTs (cont)

• 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.

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.

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

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.?
• Positions should be numbered from 1 N in
  keeping with the ADT definition

7
Example ADT List of Integers

• All lists work the same way, regardless of the
  type of data stored in the list. Well 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).

8
Design

• Assumptions
• The list will be a list of integers.
• Notice that we did not say ints. How the
  integers are implemented will be decided later
  (ints, strings, or some other representation).
• The list can hold a maximum of 100 items
  numbered 1 - 100
• The list can be empty.
• Duplicate items will not be allowed.

9
Design (cont)

• 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 kth 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

10
Operation Interfaces

• Construct a new empty list
• // default constructor
• IntListIntList(int initialSize 100)
• Construct a new list as a copy of an existing
  list
• // copy constructor
• IntListIntList(const IntList rhs)

11
Operation Interfaces (cont)

• Destroy the list
• // destructor
• IntListIntList( )
• Make the list empty
• void IntListMakeEmpty( )

12
Operation Interfaces (cont)

• Check for an empty list
• bool IntListIsEmpty ( ) const
• Check for a full list
• bool IntListIsFull ( ) const

13
Operation Interfaces (cont)

• Assign one list to another
• IntList IntListoperator (const IntList)

14
Operation Interfaces (cont)

• Insert an item into the list
• Design decision
• Boolean function
• If the item is already in the list, return false
  and do nothing
• Data, not a package (such as a node with its
  next pointer) are send to the funciton
• bool IntListInsert(int x)
• What do you think of this design decision?

15
Operation Interfaces (cont)

• Remove an item from the list
• Design Decision
• Boolean function
• If the item is not in the list, return false and
  do nothing
• bool IntListRemove(int x)
• What do you think of this design decision?

16
Operation Interfaces (cont)

• Locate the position of an item in the list
• Design decision
• Positions will be numbered from 1 - N
• If the item is not in the list, return 0
• int IntListFindPosition(int x) const
• What do you think of this design decision?

17
Operation Interfaces (cont)

• Return the item in the kth position
• Design Decision
• If the position is out of range, return 0.
• int IntListoperator (int k) const
• What do you think of this design decision?

18
Operation Interfaces (cont)

• Print the list
• Design decision
• Overload the ltlt operator rather than create a
  named function
• Make operatorltlt a friend of the IntList class
• ostream
• operatorltlt (ostream, const IntList )
• What do you think of this design decision?

19
IntList Interface

• class IntList
• friend ostream operatorltlt(ostream out,
  const IntList L)public
• IntList (int size 100)
• IntList (const IntList)
• IntList ( )
• IntList operator (const IntList ) void
  MakeEmpty ( )
• int operator (int position) const
• int FindPosition (int x) const
• bool Insert (int x)
• bool Remove (int x)
• bool IsFull ( ) const
• bool IsEmpty ( ) const
• private
• // private data and methods

20
Using IntList

• IntList L1 // a list with room for 100 integers
• int x
• L1.Insert (7)
• L1.Insert (42)
• x L11
• cout ltlt L1 ltlt endl
• L1.Remove (22)
• if (! L1.IsEmpty ( ) )
• L1. MakeEmpty ( )

21
Using IntList (contd)

• Observations
• Client (application/user) 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).

22
Using IntList (contd)

• We deliver the interface (.H) to the customer in
  source code form.
• It doesnt matter if the application programmer
  sees the representation. He/she still has no
  direct access to an IntList.
• .

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

24
Array Implementation

• class IntList
• friend . . .
• public . . .
• private
• // private member functions here
• int m_capacity
• int m_size
• int m_theArray

25
Linked List Implementation I
struct Node // using a struct as a node
int m_data
Node m_next class IntList friend . . .
public . . . private //
private member functions here int
m_capacity int m_size Node
m_theList
26
Linked List Implementation II
class Node // using an object as a
node Node( int d 0, Node n NULL ) int
m_data Node m_next friend class
IntList class IntList public //
same as before private // private member
functions here int m_capacity
int m_size Node m_head
27
Array vs. Linked List

• What are my memory requirements?
• What are my response time requirements?
• What is the relative 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)?

28
Generalized Linked List
template ltclass DATATYPEgt class List //
forward declaration template ltclass
DATATYPEgt class Node friend class
ListltDATATYPEgt Node( const DATATYPE d
DATATYPE( ), DATATYPE n NULL) DATATYPE
m_data NodeltDATATYPEgt m_next
29
Generalized Linked List (cont)
template ltclass DATATYPEgt class List public .
. . bool Insert(const DATATYPE data)
DATATYPE operator (int k) const . .
. private // private member functions
here int m_capacity int m_size
NodeltDATATYPEgt m_theList
30
Generalized Linked List (cont)
include list.H int main( ) Listltintgt
integerList ListltSomeClassgt someList
. . . return 0 (See your text for more
details on the generalized linked list
implementation.)