If you wanted to know just about everything about C++ templates than the book C++ Templates—The Complete Guide by David Vandevoorde and Niccolai Josuttis, (ISBN 0-201-73484-2) is a readable reference book you can use. Normally, discussing a book would appear in a book review. However, since the authors have done such a good job of describing C++ templates, I though the topic and the book deserved more complete coverage. You may recall Niccolai as the author of the excellent text, The C++ Standard Library, ISBN 0-201-37926-0. David is the author of C++ Solutions: Companion to the C++ Programming Language , Third Edition, ISBN 0-201-30965-3. Both authors are also longtime members of the ANSI/ISO C++ X3J16 Standardization Committee.

Most of us write the following const or volatile declaration thus:

The authors suggest that a better way is:

Here, const and volatile appear before what they qualify. Since I read declarations from right to left, in //1, I get vInt is a volatile int and in //2, I get pcChar is a pointer to a const char. The real power comes when we use this ordering in typedef statements. For example,

Here we can see that the first typedef (pointer to int) can be used in the second typedef (const pointer to int). The third typedef completely changes the meaning of the type (pointer to const int).

Historically, we have used the keyword, class, in template parameter lists:

However, T could be replaced by things other than a class name, so the use of the new keyword typename is preferred.

Often, instantiating a template can result in an ambiguity error that is difficult to understand. Here is a simple example:

The ambiguity occurs because all parameters are supposed to be of same type, but in the second case, it is unclear whether that type should be an int or a double.

In this simple example (and many others like it), there are 3 ways of disambiguating the statement:

In //3, the template type is forced to be int. In //4, casting forces all the argument types to be the same. The third way to eliminate this problem uses more sophisticate templates.

It is possible to have both template and non-template versions of the same function. Often, these non-template versions of the function are called specializations. In such situations, function overloading and its rules are used to resolve any ambiguities. Because we are talking about templates, a few added rules are needed to normal function overloading rules.

• In instantiating a template function, no type conversions are done.
• All things being equal, specialized template functions are preferred over template ones.
• If instantiating a template function results in a better match, the better match is used. By better match, we mean that things like conversions are not need to make a match.
• If the empty angle brackets notation is used, non-template functions are ignored in matching argument.

Here are some examples:

In //5, the non-template function is the best match (Rule 2). In //6, template argument deduction instantiates the cmp<double> function (Rule 3). In //7, the instantiated function is cmp<char> (Rule 3). In //8, the notation forces use of the template function and results in a cmp<int> function being instantiated and used instead of the non-template version of the cmp function (Rule 4).

When a template class or function has more than one template parameter, one or more may be specified creating a partially specialized template. However, if one or more partial specializations match the same template, an ambiguity occurs. For example,

The output from this program is:

Note that calling f(3,5) is ambiguous because both f(T,T) and f(T,int) match this call.

Both classes and functions can use non-type template parameters. When used, non-type parameters become part of the classes type and functions signature. Thus,

Each of c10A, c5A, and i10A are all distinct types.

An example of a template function using non-type parameter follows:

The output of this short program is:

Non-type template parameters have restrictions: they must be integral values, enumerations, or instance pointers with external linkage. They can’t be string literals nor global pointers since both have internal linkage.

You may have wondered why we needed the new keyword typename. Besides being a better choice for template parameters, it is needed to disambiguate certain declarations. E.g.,

Without the keyword typename, the declaration for p becomes an expression: the value of T::X is multiplied by the value of p.

Generally, prefix all declarations using template parameters with typename.

Normally derived and base classes share the value of this. However, lookup rules for template classes are different. Template base class members are not lookup when searching derived template class member functions.

In bar(), foo() would not be found. To get B’s foo, you need to say this->foo(). Again, the rule given in the book states that any base class member used in a derived class should be qualified by this-> or B<T>::.

I have not begun to cover many of the interesting aspects of templates in this short article. And I have barely covered the other fun parts of this book. Get it.

In www.redherring.com December’s newsletter, they listed for 2003 10 predictions from various experts . I was interested to see where it might lead for the Valley. The main predictions are:

• Wireless LAN's (WLANs), aka wi-fi or 802.11, will take off.
• “Virtualizing” the process of making big user's infrastructure seamless will dominate IT spending.
• No shake-out among the VCs, but continuing "make money or else" on part of 2+ stage firms.
• Stock options impact the bottom line. Tech firms are finally forced to include options as expenses in financial reports. Geoffrey James argues this point as inevitable.
• Telecom companies that have clawed their way out of bankruptcy will seek its protection again. However, there is still plenty of bandwidth left.
• Stephan Herrera points out that the bioterrorism effort will reduce biotech industry competition .

If you believe these predictions, you can see that connectiveness is driving where we are going. Bioterrorism is also going to drive more biotech. The expensing of options will reduce their importance in attracting staff.

I was contact early this month by Luby Aczel, a Volunteer Coordinator for the non-profit Northern California studio of Recording for the Blind and Dyslexic. They create and lend educational material on CD or four track cassette to individuals with learning or visual disabilities. They need volunteers to read the many technical and computer manuals for which they get requests. Please visit their web site at www.rfbd.org to find out more about them. You can also contact Luby Aczel, at 650-493-3717, ext. 13

Book Reviews

Real-Time UML: Developing Efficient Objects for Embedded Systems—2nd Edition by Bruce Powel Douglass, Addison-Wesley, ISBN 0-201-65784-8

Rating: Recommended
Reading Level: Easy.

I believe this book heralds the next step in system design, reliability, and effectiveness. On every page, new ideas jumped out at me.

Real-Time UML is geared towards the beginning to intermediate level. It presents a clear and practical approach for a reader with minimal exposure to UML and embedded systems.

The book is well organized and easy to read. It contains seven chapters. Broadly speaking, the first four chapters focus on analysis and the last three focus on design. Chapter 1 provides an introduction to objects and real-time systems concepts such as concurrency and messaging. Chapter 2 uses UML to analyze real-time systems requirements. Here, use cases are fundamental to capturing the requirements of a system. Chapters 3 and 4 focus on object analysis from two points of view. First, from a structural perspective, it explains how to identify a set of objects that is necessary to realize a set of use cases. Second, from a behavioral point of view, the author explores how do these objects communicate and relate to one another so that the system requirements can be met. Chapters 5, 6 and 7 discuss design topics. Chapter 5 emphasizes architecture, including the use of patterns appropriate for embedded systems. Chapter 6 discusses mechanistic design which involves the organization of classes to support a particular implementation strategy. Chapter 7 dives into detailed design looking at things such as data structure implementation and algorithms.

One of the most interesting topics covered in Real-Time UML is statecharts. Statecharts are a unique modeling tool that allow for better analysis of real time systems. In Chapter 4, the author introduces statecharts and proceeds to give numerous examples of practical applications.

The text is fairly accurate. The use of diagrams and clear examples is widespread throughout. Little code is presented as it is not really needed to introduce UML concepts. However; snippets of C++ can be found where they enhance the explanation of a concept.

The book is very useful for several reasons. It serves as a stepping stone for further study of OO techniques applied to embedded systems. Furthermore; since it covers three broad areas: OO, UML and embedded systems, anyone with more advanced knowledge in any of these areas can use this book to see how the other areas are tied into what they already know.

— Bernal A. Arroyo

In this month’s chart, I noticed that Windows development in the Valley seems to be weakening. That is, as a proportion of the total number of job openings offered, the percentage related to Windows has been decreasing, more so than Linux, for example.

Also note that Windows XP is hardly making an impact. There are still more job openings asking for Windows ME skills than for XP knowledge. Also, as a proportion of all the openings advertised, Linux and individual flavors of Windows are about the same.

Another interesting observation is that there was a noticeable up-tick in the jobs offered in August that has subsequently dipped. This also matches the consumer confidence index for the same period.