CS62 - Spring 2010 - Lecture 23

  • big3 exercise

  • administrative
       - CS senior presentations this week:
          Thursday 4:15-6pm
          Friday 3:30-5:30pm

          in Edmunds 101 (down the hall)
       - Pre-registration pizza on Thursday at 6pm
       - Lab Wednesday is optional and will be a work session for this week's homework

  • file streams
       - ofstream fout(filename.c_str());
       - ifstream fin(filenmae.c_str());

  • destructors
       - Anything wrong with doing the following in Java?
          Vector v = new Vector();
          v = new Vector();

          - nope
          - functionally everything works fine. v now points to a new Vector object on the heap
          - eventually, the garbage collector will notice that the original Vector object is free and reclaim it
             - when can an object be garbage collected?
                - when there are no references remaining to that object
       - what about in C++?
          vector<int>* v = new vector<int>;
          v = new vector<int>;

          - functionally, everything works fine
          - the problem, is that C++ is not garbage collected
          - we now have a chunk of memory that we cannot access, but also cannot reuse
       - in C++ we need to explicitly tell the memory manager that we're done with that memory
       - the "delete" command does this:
          vector<int>* v = new vector<int>;
          delete v;
          v = new vector<int>;
       
          - we told the memory manager that we don't need the memory allocated to the first object
       - objects can be very complicated. how does the memory manager know what memory to free up?
       - the destructor: one final method that the compiler provides a default implementation for:
          ~MyClass()

          (opposite of the constructor)
       - the destuctor is called when an object is no longer needed
          - when a variable's scope is disappearing
             - for example, a local variable when we return from a method
          - when the programmer explicitly calls delete on an object
       - what do you think the default behavior for the destructor is?
          - recursively calls delete on all of the member variables
             - doesn't matter for built-in types

  • look at the clear() method in linkedlist.cpp code
       - any problems with this?
          - we're not cleaning up our memory!
       - look at clear() method in linkedlistimproved.cpp code
          - recursively removing elements from the list until it's empty
          - are we done?
             - still haven't actually called delete on any of the nodes to free them up
          - how would we do that?
       - look at removeFirst() method in linkedlist.cpp
          - how would we change it to appropriately "delete" objects
       - look at removeFirst() method in linkedlistimproved.cpp code

  • memory management
       - in general, everytime you create an object on the heap using "new" you should make sure that you're calling delete appropriately somewhere else in your code
       - memory management is hard!
       - pitfalls
          - memory leak (forgetting to delete an object)
          - deleting memory before it's actually freed up
             vector<int>* v = new vector<int>;
             vector<int>* v2 = v;
             delete v;
             v2->push_back(10);
          - double deleting memory
             vector<int>* v = new vector<int>;
             vector<int>* v2 = v;
             delete v;
             delete v2;

  • operator overloading
       - we saw how to overload the = operator
       - in general, you can overload almost any operator (there are a few exceptions, though)
       - basic steps:
          - add the appropriate function header for the operator
             - the function names all start with "operator" followed by the actual operator
             - you just have to get the number of arguments and the return type correct, but you should be able to figure it out
             - http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B
          - add the function definition to the .cpp file
             - make sure you konw what you're doing, since operators are important :)
       - look at operator[] overload in the linked list lcass in linkedlistfinal.cpp code
          - int& LinkedList::operator[](unsigned int index)
             - overriding the [] operator of the LinkedList class
             - why an unsigned in?
                - can't have negative indices
             - why the int& return typ?
                - out linked list is storing ints
                - it needs to be return-by reference and not value, so we can do things like:
             
                   LinkedList l;
                   ...
                   l[4] = 7;

                   and actually have it change the dataq. Since the int returned from the operator method is the SAME as the one we're modifying in the statement. Make sure you understand this distinction!

  • graphs
       - A graph is a set of vertices (or nodes) V and a set of edges (u,v) in E where u, v are in V
       - there are different types of graphs (show some examples)
          - undirected
             - if an edge (u, v) exists (that is u is connected to v) then (v, u) also exits, that is, v is connected to u
             - when drawn, we'd draw the edge between u and v as a line
          - directed
             - edges have a direction, that is, u may be connected to v, but not necessarily vice versa
             - when drawn, we'd draw the edge from u to v as an "arrow"
          - weighted
             - each graph edge has an associated weight
             - can have either weighted, undirected graphs or weighted, directed graphs
       - graph terminology
          - path
             - a path is a list of vertices p_1, p_2, ..., p_k where there exists an edge (p_i, p_{i+1}) in E
             - intuititvely, it's a connection of edges
             - a "simple" path is a path where all edges are unique
          - cycle
             - a simple path with p_1 = p_k
             - look at cycles in directed and undirected graphs
             - a graph is called "acyclic" if it doesn't have any cycles in it
          - connected
             - a graph is connected if every pair of vertices is connected by a path
             - for directed graphs, this is called "strongly connected"
             - "weakly connected"?
                - if replacing all of the directed edges with undirected edges leaves a connected graph
       - where have we seen graphs in this class already?
          - tree
             - undirected
             - acyclic
             - note that we have to specify a root
       - some other special cases
          - twig
          - ring
          - complete graph
             - an edge exists between every node
          - bipartite graph
             - a graph where every vertex can be partitioned into two disjoint sets X and Y, such that all edges connect a vertex u in X to a vertex v in Y   
       - what are some questions we might want to ask about graphs?
          - does it have a cycle?
          - is it connected? strongly connected? weakly connected?
          - is there a path from a to b?
          - what is the shortest path from a to b?
          - do graphs have the same structure (these are called isomorphic graphs)?

       - where do graphs come up in real life?
          - transportation networks (flights, roads, etc.)
             - flights
                - directed or undirected?
                - weighted?
                - what are the weights?
             - google maps
                - directed or undirected
                - weighted?
                - what are the weights?
          - communication networks
             - computer networks
             - phone networks
          - web
             - what are the vertices and edges?
                - vertices are web pages
                - edges are links
          - social networks
             - what are the vertices and edges?
                - vertices are people
                - edges are relationships (e.g. friends on facebook)
          - circuit design
          - bayesian networks
    •