These short courses bridge the gap between a comprehensive C++ programming course, such as PR12C, and a working command of important programming situations. They're suitable:
Each of these courses occupies a unique and important niche in the C++ programmer's repertoire, serving as a foundation for many kinds of application programming as well as for Windows; or other GUI platform software development.
They're advanced not in the sense of highly sophisticated or difficult, but simply as topics not covered by most C++ courses and textbooks. Most of them are independent of each other, and can be taken in any sequence by programmers who have general competence in C++/OOP.
| Course Number | Title |
| CPP-11 | Designing and Implementing an Elementary Item Class in C++ |
| CPP-20 | Defining and using Matrix classes in C++ (double-session) |
| CPP-14 | Exploiting C++ Templates to Implement Dynamic Data Structures |
| CPP-06 | Bringing C++ Character Strings Under Control |
| CPP-15 | Anatomy of Recursion |
| CPP-16 | Designing and Implementing Entity Classes for Business Applications |
| CPP-17 | Error and Exception Handling: beyond throw and catch |
| CPP-01 | Macros to Simplify and Standardize Class Definition |
| JAV-01 | Introduction to Java for Experienced C++ Programmers |
| CPP-13 | Exploiting Smart Pointers and Iterators |
| ---- | CORBA and Active X
courses are under development. Ask us about other topics |
Just as valuable but often overlooked are C++ classes for elementary data items that every application needs. A well designed C++ elementary item class:
However, developing C++ classes, even for elementary data items, is itself tedious, error-prone, and full of pitfalls. Designers and senior programmers who can build reliable and easy-to-use classes will make major contributions to the quality and productivity of their organizations' application software development and maintenance.
Prerequisites:
Participants should have a good knowledge of C's built-in data types and a general knowledge of C++'s class definition mechanism.
Description:
We begin by reviewing the four natural categories of elementary data items: discrete, numeric, text, and logical. For each of them we examine criteria for internal and external data representations, illustrating the concepts with C++ classes.
Taking examples from each category, we design and code the appropriate constructors, accessors, and I-O stream operators to support our chosen data representations.
For each example we consider the repertoire of operators, noting not just the ones we must implement, but also those we must not implement and those that yield a result of some other class. We show the implementation of enough overloaded operators to serve as a model.
In the important case of numeric classes, we pay close attention to the integrity of the unit of measure. We distinguish carefully between the notions of point and extent, and show how to package recurring patterns for reliable reuse.
We complete each class's public interface by designing additional member and non-member functions needed to provide minimal and complete functionality.
Finally, we illustrate the use of our class definitions, discuss their practical impact on application development, and assess an organization's return on investment in developing them.
Return to top.
Return to course list
(new standard library version)
C was notoriously weak in character-string operations. C programs either avoided string manipulation (at a sacrifice in flexibility and user-friendliness) or contained clumsy code (at a cost in future maintenance and operational reliability).
C++, with its ability to define new data types and to hide ugly representation details, raised hopes that this deficiency might be overcome through definitions of classes and methods. So far, however, no string class has emerged as a fully satisfactory standard, and programmers still struggle with awkward and incomplete solutions to this long-recognized problem.
The new standard C++ class library includes a string class which helps solve some but not all of these problems.
We conclude that we need three related but distinct string classes to support the needed functionality.
We then consider alternatives for internal string representation, based mainly on C's array of char. We discuss pros and cons of including C's conventional null-terminator in the representation, and the trade-offs in using existing C library functions in the implementation. We sketch the implementation of one string class, writing the constructors, destructors, accessors, and the tricky overloaded assignment operator.
We consider the use of reference counting as a way of improving efficiency, and show why that technique is seldom worth the complications it introduces.
We then examine the need for more functions and operations to provide substring, search, concatenation, and other commonly needed functionality, and examine implementations of those we decide we need.
Next we look at an approach to implementing contiguous fixed-length strings, thus (unlike most textbook string classes) allowing character fields to be embedded in records and other structures. (This is considered an essential capability by most business applications developers.)
We complete our multiple string classes by examining the conversions among them, noting pitfalls in designing constructors and conversion operators. In particular, we consider the consequences of conversion to a C array of char, in order to allow the use of existing C functions on string objects.
Finally, we examine the standard C++ library String class, noting which of our three string classes it can replace and how its use would affect our interfaces.
As time permits, we go through examples of the effective use of our string classes in realistic programming situations.
Return to top.
Return to course list
Actually, judicious use of recursion can sometimes help a programmer to simplify logic in fairly mundane applications, and recursive implementations are often more efficient than a non-optimized non-recursive equivalent.
Prerequisite:
Description:
We first lookat four ways of implementing a simple integer power function in C. For the recursive versions, we trace the execution through successive invocations. We then review the function template facility, illustrating it with small utility functions. We then take on more interesting examples that combine recursion with templates, starting with an efficient sort function, and moving on to other "divide and conquer" algorithms. We introduce the notion of mutual (indirect) recursion.
We conclude with a discussion of performance efficiency and ways of tuning a recursive function. We also warn the participants against over use of recursion in situations that don't really need it, showing examples where it is inappropriate.
Return to top.
Return to course list
The main reason the C++ community has been ignoring entity classes lies in the lack of C++ support for persistent objects that can be stored in files and databases. That deficiency, however, shouldn't deter developers from exploiting C++ to implement object-oriented application models. Such implementations typically present opportunities to exploit inheritance and polymorphism in ways that greatly simplify testing and future maintenance.
Prerequisite:
Description:
We review briefly the structure and expected content of a system specification, both object-oriented (Booch, Coad & Yourdon) and standard (DeMarco, Gane & Sarson) structured analysis, and discuss how it serves as the point of departure for designing C++ classes. For our first example, we design a Person class, and then consider the kinds of derived classes various applications might base upon Person. We take great care to distinguish between the is-a relationship and the often neglected plays-the-role-of relationship.
We then examine other kinds of classes that appear in typical accounting, manufacturing, retailing, or other applications, choosing examples depending on participants' interests and backgrounds. (For in-house presentations to groups working on common applications, we can customize the examples in advance.) Wherever possible we show how polymorphic methods simplify program logic, but we warn against distorting a design for the sake of inappropriate polymorphism.
We conclude by confronting the persistent object problem, and briefly discuss alternative strategies for C++ interfaces with databases.
Return to top.
Return to course list
Judicious use of these facilities in combination with other techniques is essential in building a robust and maintainable application. Even more important than the use of particular facilities, however, is the way a large program is organized to communicate information across separate modules.
Prerequisite:
Description:
We examine the structure of a typical transaction editing program, in which various functions may encounter errors. A low level validation / conversion function may know the nature of an error but doesn't know where the data came from or how to communicate with the user. A high level control function knows where the data came from and how to communicate with the user, but doesn't know exactly what errors have occurred. Our challenge is to develop a program structure in which information is known at exactly the right point without burdening every function with awkward communication of status information.
We first examine some of the older approaches used in C/C++, such as set_new_handler communication points. We show where that approach works well and where it is insufficient.
We then present C++ class-based exception handling facilities: try blocks, catch blocks, and throw statements. We explain the limitations of non-resumptive processing, and suggest techniques for circumventing them. Through realistic examples we propose conventions for simplifying and standardizing exception handling.
Return to top.
Return to course list
Judicious use of old-fashioned C macros can help us to simplify the class definition process, to minimize repetition, to avoid common errors, to enhance readability, and to standardize the sequence and the look of our class definitions.
Prerequisite:
Description:
We examine typical class definitions for elementary, composite, and container types, noting things that are awkward, repetitive, hard to find, or error-prone. We consider alternative ways of overcoming those shortcomings.
We then show the equivalent class definitions implemented through the use of a package of class-definition macros, noting that they're shorter, easier to read, and easier to change.
We then show some more interesting examples that implement reuse of design patterns through further use of the preprocessor.
We proceed to show how to extend the macros to support single and multiple inheritance.
To the degree that the participants are interested, we conclude by examining the macro definitions themselves, noting certain techniques that would not be obvious at first.
Return to top.
Return to course list
One reason is to develop applets to run under a platform-independent Internet Web browser. Another is that Java is becoming more and more popular as a general-purpose object-oriented language and is a tool that today's professionals are expected to be well acquainted with.
Enthusiasts point out that Java is a simpler language than C++. Indeed, Java has eliminated some troublesome and error-prone aspects of C++, including pointer manipulation and memory management. But Java's simplicity often carries a price, by comparison with C++, in more costly maintenance and in reduced potential for code reuse. This seminar takes a balanced view, presenting Java's positive features without overlooking its shortcomings.
Prerequisite:
Description:We review quickly the common core of C++ and Java. We proceed to explain Java's concept of reference data types, noting that they may hide pointers but the programmer must still be aware that the pointers exist and write code accordingly. We explain the principle of garbage collection and how it relieves the programmer of responsibility for memory management.
We explain how the Java compiler and interpreter work, and stress the platform independence of so-called byte code.
We then compare typical C++ and Java class definitions, noting the strengths and weaknesses of each version, and showing how to circumvent the weaknesses.
If time permits, we conclude by examining the Web applet concept.
Return to top.
Return to course list
The standard template library (STL) supports a broad variety of one-dimensional containers, but offers little help to users who need to manipulate two-dimensional (or higher) arrays. In the absence of any standard organizations and even individual projects have to design and develop their own matrix classes. Dozens, if not hundreds, of such mutually incompatible classes now exist, using a huge variety of techniques, some good, some bad.
We seek to provide in one or more Matrix classes:
This course expands upon concepts and techniques covered in the first half of the former CPP-14, Exploiting Class Templates. We developed it to meet the needs of clients for whom matrix manipulation is far more important in their applications than exploiting dynamic data structures.
In this short course we focuse on the container aspects of matrix manipulation and don't go into numerical methods of matrix algebra.
CPP-20 course offers guidance on how best to implement such classes, answering these questions:
Matrix class be related to a
one-dimensional array class? Should we
Matrix from the STL's Vector?
Vector as a member of
Matrix?
a[i][j]
a(i,j)
a.getElement(i.j)?
*acolp(*arowp + i) + j
This course explores these questions, shows alternative C++ solutions, and recommends preferred approaches. Participants will receive a small class library containing working versions of the examples.
Between the two sessions, the participants get a chance to design and develop their own C++ class(es), following the principles and techniques presented in the first session.
Return to top.
Return to course list