CPSC 427a: Object-Oriented Programming

Michael J. Fischer

Lecture 23a
November 29, 2011

Privacy

• How privacy attributes are determined.
• How privacy attributes affect visibility.
• How to use privacy to support OO-programming.

Code efficiency

• How to measure running time.
• How to build an adaptor class (Stopwatch) to a system resource (struct timeval).
• Defining and using a cast.
• Efficiency of various kinds of containers.
• Runtime tester.
• Use of member function pointers.

15-Hangman game demo

• Use of derivation for classes Alphabet and HangWord.
• The StringStore data structure and its implementation.

15-Hangman-full game demo

• Removing fixed size limits in StringStore and the vocabulary.
• Definition and use of a template class.
• Introduction of a new class Player. Why was this done?

Templates

• Purpose of templates.
• Contrast variability using templates with variability through polymorphic derivation.
• Template functions.
• Specialization.
• Template classes.
• Code structure and compiling templates.
• Template parameters
• Examples: 15-Hangman-full and 16-Evaluate.

C++ standard library

• Containers. Focus on understanding vector, list, and map.
• Use of class pair.
• Meaning of value semantics.
• Iterators: What they are; how to use them.
• Other container functions: operator[](), size().
• Standard algorithms.
• Defining a comparison function for use with std::sort().
• string class.

Casts and conversions

• Kinds of casts in C: value, pointer,
• Kinds of casts in C++: static, dynamic, reinterpret, const.
• Three different syntaxes for explicit casts.
• Implicit casts.
• Resolving ambiguity.
• explicit keyword.

Operator extensions

• Correspondence between operator symbols and operator functions.
• Special cases: operators that can be either prefix or postfix (++, --).
• Other special cases: subscript, arrow, function call, cast, new, delete.

Polymorphism and virtual functions

• When to use?
• What happens to a virtual function when inherited by a derived class?
• Abstract class and interfaces.
• Examples 18a-Dynamic_cast, 18b-Virtue, and 18c-Virtual.
• Dependency graph for include files.

Exceptions

• What are exceptions?
• Why is a special exception-handling mechanism needed?
• How is an exception signaled? throw.
• How is an exception handled? try and catch blocks.
• Standard exceptions and how to catch them.
• Multiple catch blocks.
• rethrow.
• Avoiding need to rethrow by putting resource cleanup code into destructors.

Multiple inheritance and ordered container examples

• Demo 20a-Multiple.
• Element ordering, keys, and comparison operators.
• Multiple inheritance.
• Object structure with multiple inheritance.

Tightly-coupled classes and circularity

• What it means to be tightly coupled.
• Problems with #include.
• How to resolve circularity: forward declarations; out-of-line function definitions.

Templatized ordered linear data structures

• Examples 20b-Multiple-template and 21a-Multiple-template combine templates with polymorphic derivation.
• How is each used?
• How is the KeyType template parameter used? Who defines it? Who uses it?

STL and Polymorphism

• Why do some people say never to use STL containers as base classes?
• When is it safe to do so?
• Under what situations might there be problems?

Simple versus polymorphic derivation

• What is simple derivation good for?
• What are its advantages and disadvantages?
• What is polymorphic derivation good for?
• What are its advantages and disadvantages?
• Composition as an alternative to derivation.

Design patterns

• General OO principles
• What does a design pattern consist of?
• Adaptor pattern.
• Indirection pattern.
• Proxy pattern.
• Polymorphism pattern.
• Controller pattern.
• Bridge pattern.
• Subject-Observer pattern.
• Singleton pattern.

Software design process

• The Waterfall process.
• The Spiral process.
• OO-design.
• Code reusability.
• Reducing dependencies among classes.
• Building in flexibility.
• UML notation.

User Interfaces Modern computer systems support two primary general-purpose user interfaces: Command line: User input is via a command line typed at the keyboard. Output is character-based and goes to a physical or simulated typewriter-like terminal. Graphical User Interface (GUI): User input is via a pointing device (mouse), button clicks, and keyboard. Output is graphical and goes to a window on the screen.

Interfaces for C++

The C++ standard specifies a command line interface: iostream and associated packages. No similar standard exists for GUIs.

De facto GUI standards in the Linux world are GTK+ (used by the Gnome desktop) and Qt (used by the KDE desktop).

GTK+ is based on C; Qt is based on an extension of C++ and requires a special preprocessor.

gtkmm is a C++ wrapper on top of GTK+. Advantages: Provides type safety, polymorphism, and subclassing.
Provides a native interface to C++ code.
Disadvantages: Components not so well integrated.
Documentation spread between gtkmm, gtk+, and other components but improving.

Overall Structure of a GUI

A GUI manages one or more windows.

Each window displays one or more widgets.

These are objects that provide graphical and textual input and output to the program.

A GUI package such as gtkmm maintains a widget tree.

A widget controls a particular kind of user input or output.

Examples: label, text box, drawing area, button, scroll bar, etc.

Concurrency and Events

The central problem in building a GUI is handling concurrency.

Data arrives from multiple concurrent sources – mouse and keyboard, network, disk, other threads, etc.

We call the arrival of a piece of data an event.

• Event arrival times are unpredictable.
• Events should be processed as quickly as possible.

For example, to have a good interactive feel, the GUI should respond to a mouse click event within milliseconds.

Event Loop

An event loop allows a single thread to manage a set of events.

At some level, the hardware or software polls for events.

When an event is detected, it is dispatched to an event handler.

The event handler either processes the event itself, queues a task for later processing, or spawns a thread to process it.

While the event thread is processing one event, no other events can be processed, so event handlers should be short.

Problem is to prevent a long-running low-priority event handler from delaying the handling of a high-priority event.

A GUI event structure

A GUI typically translates raw hardware events into semantically-meaningful software events.

For example, a mouse click at particular screen coordinates might turn into a button-pressed event for some widget in the GUI tree.

Several system layers may be involved in this translation, from the kernel processing of hardware interrupts at the bottom level, up through device drivers, windowing systems such as X, and finally a GUI frameworks such as GTK+.

Interface between user and system code

A major software challenge is how to design the interface between the GUI and the user code that ultimately deals with the events.

In a command-line interface, the user code is at the top level.

It connects to the lower layers through familiar function calls.

With a GUI, things are turned upside down.

• The top level is the main event loop.
• It connects to the user by calling appropriate user-defined functions.

Binding system calls to user functions

How can one write the GUI to call user functions that did not even exist when the GUI system itself was written?

The basic idea is that of interface.

• The interface is a placeholder for the eventual user functions.
• It describes what functions the user will provide and how to call them but not what the functions themselves are.
• The interface is bound to user code either when the user code is compiled or dynamically at runtime.

Polymorphic binding

C++ virtual functions provide an elegant way to bind user code to an interface.

• The GUI can provide a virtual default event handler.
• The user can override the default handler in a derived class.

Of course, the actual binding occurs at run time through the use of type tags and the vtable as we have seen before.

Binding through callback registration

The user explicitly registers an event handler with the GUI by calling a special registration function.

• The GUI keeps track of the event handler(s) registered for a particular event.
• When the event happens, it calls all registered event handlers.

This is sometimes called a callback mechanism since the user asks to be called back when an event occurs.

Callback using function pointers: GUI side

Callbacks can be done directly in C. Here’s the GUI code:

1. Define the signature of the handler function:
   typedef void (*handler_t)(int, int);
2. Declare a function pointer in which to save the handler:
   handler_t buttonPressHandlerPtr;
3. Define a registration function:
   void systemRegister(int slot, handler_t f) {
     button_press_handler_ptr = f;
   }
4. Perform the callback:
   buttonPressHandlerPtr(23, 45);

Callback using function pointer: User side

Here’s how the user attaches a handler to the GUI:

1. Create an event handler:
   void myHandler(int x, int y) {
     printf("My handler (%i, %i) called\n", x, y);
   }
2. Register the handler for event 17:
   systemRegister(17, myHandler);

Type safety

The above scheme does not generalize well to multiple events with different signatures.

• Registered handlers need to be stored in some kind of container.
• For type safety, each different handler signature requires a different event container and registration function of the corresponding signature.

The alternative is for systemRegister() to take a void* for its second argument and to cast function pointers before call them.

This is not type safe and can lead to subtle bugs if the wrong type of function is attached to a callback slot.

Signals and slots

Signals and slots is a more abstract way of linking events to handlers and can be implemented in a type safe way.

• A connect() template function is used to bind a signal to a slot.
• An event emits a signal.
• A handler is associated with a slot.
• Whenever the event occurs, the functions associated with all connected slots are called.

Several signals can be connected to the same slot, and several slots can be connected to the same signal.

Structure of gtkmm gtkmm relies on several libraries and packages:

• gtkmm-2.4 is the GUI engine.
• gdkmm is a device layer used by gtk.
• cairomm is a vector graphics drawing package.
• pango is a library for laying out and rendering of text, with an emphasis on internationalization.
• sigc++ is a library for connecting events (signals) to event handlers (slots).

Compiling a gtkmm program

Many include files and libraries are needed to compile and build a gtkmm program.

A utility pkg-config is used to generate the necessary command line for the compiler.

Linking a gtkmm program

pkg-config also generates the necessary linker flags.

To use package config, use the backquote operator on the g++ command line:

Compiling: g++ -c ‘pkg-config gtkmm-2.4 --cflags‘ ...

Linking: g++ ‘pkg-config gtkmm-2.4 --libs‘ ...

Both: g++ ‘pkg-config gtkmm-2.4 --cflags --libs‘ ...

Using a GUI

The following steps are involved in creating a GUI using gtkmm:

1. Initialize gtkmm.
2. Create a window.
3. Create and lay out widgets within the window.
4. Connect user code to events.
5. Show the widgets.
6. Enter the main event loop.

The GUI then displays the window and waits for events.

When an event occurs, the corresponding user code is run.

When the event handler returns, the GUI waits for the next event.

Example: clock

The code example 22-clock is a significant extension of the clock example in the gtkmm tutorial book.

It illustrates many of the features of gtkmm.

Main program