C++ is a large and complex language, supporting many different styles of programming. In our opinion, it is best to "learn it twice". One first needs to acquire a familiarity with the basics of the syntax, and a familiarity with the basics of a C++ style—object-oriented typically being the most useful. Then, after a few weeks' practice, we believe one should re-examine the language with an aim of acquiring an in-depth appreciation of what is in the language, of the way in which it works, of the best practices for a couple of styles (typically object-oriented C++ and generic C++) and of the majority of the traps and pitfalls. One must also make a significant start on the contents of the standard library, including that part of it commonly known as the STL.
This course presents the in-depth, "second pass", re-examination of C++.
This is a hands-on course with most of the topics exercised during the incremental development of an industrial-strength class from its naive beginnings to a trustworthy, production quality template class.
This is not a first programming course, nor is it a first C++ course.
This course will be of interest to those who already have some knowledge of C++, but who suspect that it might only be a superficial knowledge, and who would like to deepen their understanding. Typical participants would probably have found themselves needing to use C++ as a critical part of a strategically important project.
The course lasts four days.
It is based on a cycle of theory-language-practice-review, with approximately two cycles per day. One non-trivial, practical case-study is developed during the course. Each day will start at 09.30 and finish at 17.00, with an hour for lunch. Time is available at the end of the day for extended discussions or related issues.
We look at the influences on C++, its history and its culmination in standard C++. We also have a tiny guess at what might be coming up in the first revision of the standard over the next couple of years. We review the different styles of C++: object-oriented, generic, mix-in, structured, etc.
We take a brief look at the rationale behind, and mechanisms involved in, dividing a C++ system among several files. We are led to understand the jobs of the preprocessor, the compiler and the linker. We begin to look at improving the time to compile.
It helps to understand a little of what's involved in the lexical analysis of C++. We look at the various different kinds of tokens and at the job of the lexer. We are also led to look very briefly at line endings, columns and comments.
The primary expressions, and the operators and their operands will already be familiar to participants. In this chapter we are on the lookout for the subtleties, and any traps and pitfalls. We look, for example, at why most operators do not define the evaluation order of their operands, and which ones do, and why; and we ask why the conditional operator (arithmetic if) is present when there is also an "if/else". That leads us to statements ...
Understanding the difference between expressions and the various statement forms can deepen understanding of C++, and of C++ compiler error and warning messages. That the "if/else" construction is a statement in C++ and not an expression (as it was in Algol) provides our explanation of the presence of the conditional operator. Much of the syntax of statements will already be known, so once again we are looking for subtleties, traps and pitfalls.
While the basics of the type system will already be known, most of us can probably benefit from spending time ensuring that we thoroughly understand pointers, strings, arrays, array arguments, argument passing in general, and references. It is particularly important to understand the traps and pitfalls of the many different ways of passing and returning by value and by reference.
One's first object-oriented programming course often gives the impression that classes are relatively straightforward. Here we re-examine the diverse roles of classes: defining object, making object, defining the type system, storing default implementations and providing class boiler-plates (or mix-ins). We also start to consider such guidelines as "never instantiate a base class" and "prefer composition and delegation over inheritance unless type inheritance is also involved".
It is as important to understand why the special functions are special and why they should normally be provided, as it is to understand how they work and how to implement them. Here, then, we cover the rationale, the details, the construction, the traps and the pitfalls of the default constructor, the copy constructor, the copy assignment operator and the destructor.
The copy assignment operator of the previous chapter leads us on to the subject of operator overloading in general. On the face of it, very neat and cool things look possible; but, as we discover, there's plenty of opportunity to use operator overloading wrongly and to provide counter-intuitive or dangerous functionality.
The five possible different kinds of C++ memory are covered here in detail. We return to the subjects of pointer and references and to passing to and returning from functions, and the traps and pitfalls therein, such as bit slicing and the passing out of stack and temporary addresses.
Apart from conversions (covered a little bit later), garbage collection probably causes more anguish than any other feature (or anti-feature) of C++. We look at how garbage accumulates, why we need to collect it, why C++ doesn't do it for us, why collecting it is not straightforward, and at what help there is from garbage collection add-ons and from smart pointers.
One of the best things to come out of the standardization of C++ was the namespace mechanism. It is good; and it is reasonably straightforward. (We struggled to come up with more than one trap or pitfall!)
We look at both sides of the exception syntax and the major pitfalls of throwing exceptions, handling exceptions and surviving exceptions. Exceptions are one of the most difficult areas of software engineering, particularly in C++; accordingly there is a 1-day follow-up exception course available, based around the famous "Cargill Challenge". One kind of smart pointer has already been covered in the memory model chapter; in this chapter we dip into the library again, and examine the auto_ptr smart pointer that helps us survive exceptions.
Although we will have encountered derivation (inheritance) several times already, this chapter focuses on the associated traps and pitfalls of derivation—the fragile base class (superclass), for example . We look at static and dynamic binding (polymorphism in C++) and we look in more detail at abstract classes and abstract (pure virtual) member functions. The access categories are finished off, multiple inheritance is examined, countenanced for interface inheritance but not for implementation inheritance, and virtual inheritance is covered.
The principal subject here is conversion. We look at the details of implicit conversion (system and user) and explicit conversion via the old and the new cast syntax.
There are a few "operators", such as typeid that remain to be covered. We are also led to look at the RTTI (run-time type identification) and its pitfalls.
We look at why templates are necessary, what goes wrong if a language doesn't have them, and how to use them successfully and safely.
Much of the standard library, especially streams, will already have been covered. Here we focus on that area of the standard library traditionally known as the STL (standard template library)—one of the most impressive examples of generic programming known to programming-kind.
We recommend that there are no more than 10 participants, with the best results usually obtained when there are at least 8 participants. It is possible, by negotiation and mutual agreement, for more than 10 participants to be present.
A C++ class is incrementally developed from its naive beginnings, through its gradual improvement into an industrial-strength, production-quality class, and finally its transformation into a powerful and safe template class.
Please contact Matrice by telephone on +44 7010 704705; by fax on +44 7010 704706; by emailing bookings@matrice.co.uk; or by visiting http://www.matrice.co.uk
Questions or problems regarding this web site should be
directed to webmaster@matrice.co.uk.
Copyright © 2005 Matrice. All rights reserved.
Last modified:
Tuesday, 07-Jun-2005