Tech Talk

Policy Classes

By Reg Charney

In Andrei Alexandrescu’s book, Modern C++ Design, (that is reviewed on page 2)., Andrei introduces the concept of Policy Classes. They brilliantly exploit the strengths and weaknesses of templates, incomplete instantiation, polymorphism, and operator overloading to produce more robust and flexible classes and programs.

A policy defines a class interface or a class template interface. A given policy can be implemented using one or more policy classes. Those classes that use policy classes are called host classes. Policy classes are inherited by, or contained in, host classes.

Since policy classes depend on templates, Listings 1 and 2 show examples of template types that will be used later in this article. The first example shows preheating an oven to a target temperature for a given time.

// types of temperature measurements
class C { }; // Celsius
class K { }; // Kelvin
class F { }; // Fahrenheit

// types of timing scales
class Secs { };
class Mins { };
class Hrs { };

// generic function: type of time & temperature vary
template <class Time, class R>
R PreHeat(const Time& t, const R& r) { return r; }

// partial specialization: temperature type fixed
template <class Time>
C PreHeat(const Time& t, const C& c) { return c; }

// all specialized: fixed time and temperature types
template <>
C PreHeat<Mins,C>(const Mins& m,const C& c){ return c; }

template<class T> class Cook : public T { };

int main()
{
    Hrs h;
    K k;
    k = PreHeat(h, k);

    C c;
    Secs s;
    c = PreHeat(s, c);

    return 0;
}

Listing # 1: Template function examples

Listing 2 shows some template classes using type and non-type template parameters. In the example, an identification class uses a long as its basic type. The buffer class, Buf, uses the non-type argument int to set the size of buf_.

// template class examples
//
// generic template class
template<class T> class ID { T id_; };

// template class using non-type parameter, int.
template<class T, int n=512> class Buf { T buf_[n]; };

int main()
{
    ID<long> id;
    Buf<char,1024> large_buf;
    Buf<char>      small_buf;

return 0;
}

Listing #2: Simple template class example

Listing 3 shows an example using template template classes and policy classes, LO and SO. Database class instance db of OT type objects uses the SO allocator policy class.

// database application example
//
// DB is database of type T objects using
// allocation policy class Alloc<T>
//
// There are two allocation techniques depending on
// the object type, one for:
//
//     large objects (LO); and
//     small objects (SO)
//

template< class OT, template< class > class Alloc >
class DB : public Alloc<OT>
{
    /* ... */
};

class OT { }; // Object types
template<class T> class LO { };// Large Object allocator
template<class T> class SO { };// Small Object allocator

int main()
{
    DB<OT,SO> db; // create database for objects of type
                  // OT with small object allocation

return 0;
}

Listing #3: Template template class example

Policy classes look like traits, but they emphasis functionality as opposed to type. In fact, most policies don’t even have any data members.

One of the most striking things about host classes is that you can change their implementation at compile time from outside their definition. For example, how you cook can be changed by changing the oven being used. Note that because policy classes work at compile time, they complement the polymorphism available at run time.

Using policies, you can change the behavior of host class in a type safe way.

Starting with minimum host classes, you can add features incrementally using policies. These augmented host classes will evolve elegantly from minimalist to more full featured host classes.

Dos and Don’ts

On the left hand side of an assignment, you can use a conversion constructor. On the right hand side, you can use a conversion operator. The compiler will invoke the appropriate one.

Conversions that implicitly change the ownership of an object should not be allowed.

Host classes that require conversions should initialize and then copy their policy classes, policy by policy.

Defining policy classes.

This is a four step process during the design stage:

The use of policy classes should solve a lot of design tradeoffs that I have seen.

Editorial

By Reg. Charney

Microsoft vs. Java

The vicious fight between Sun and Microsoft has reached new heights.

As my Trend columns have shown, Java is the most popular language to arise in this Internet age. All modern browsers support Java applets and JavaScript. Many applications use both as their development environment. Now Microsoft is droping all support of Java, with the implied cessation of support for JavaScript also.

Since over 70% of all desktop browsers are Internet Explorer, removal of Java support from future versions of IE will affect a huge number of users.

Java’s growth threatens Microsoft’s monopoly of the desktop. To counter this threat, Microsoft wants to replace Java by its own proprietary language, C#. This may be a good short term tactic for Microsoft. However, I believe it is disastrous for developers and computer users in general. I can’t imaging the anger and sense of betrayal that Java developers are feeling right now. Under these circumstances, I don’t see how Microsoft is going to second these developers to now work for them.

Underlying the hype for Java was the hope that we could achieve cross platform application development – the “write once, read many times” mantra. Microsoft has now made this goal almost impossible. Sadly, this fragmentation was inevitable. Sun and Microsoft are both trying to gain a competitive edge by using proprietary technology. In doing this, users have lost out.

Again, the Open Source movement is the solution to this trap of depending on proprietary software! We need a language and browser that is not owned by any one entity.

Book Review

by Max Khesin

Modern C++ Design by Andrei Alexandrescu, Addison Wesley, ISBN 0-201-70431-5

I highly recommended this book if you are interested in generic techniques and Design Patterns

This book uses C++ and Generic programming techniques to implement GoF Design Patterns [1]. It introduces Andrei’s “Generic Design Patterns Library”, called “Loki”. Loki’s techniques are more important than the library itself and should be applicable in many other contexts. (Since the library is not yet available, I cannot comment on it further.) One word of caution (lest you get overly excited) – Loki uses some of the latest C++ features and requires standard-adhering compilers [g++ v2.95.2-5, Borland C++ v5.5, and EDG’s v2.45 or later. Microsoft’s VC++ 6.0 fails—Ed.]

The book is written for intermediate or expert level programmers. A fair knowledge of C++, particularly templates, is needed Also, some knowledge of Design Patterns is useful, although not strictly necessary, since the book describes the patterns in a pretty self-contained fashion.

With these prerequisites the book makes for quite an enjoyable read, but I would not call it easy due to the inherently complexity of the material covered. Andrei’s writing style is frank and friendly, which makes the reading easier.

I found the code fragments to be very accurate bar some mechanical/typesetting errors, some of which will be fixed by the time of the printing. The book’s strong points include:

1) Taking techniques as complex as template meta-programming and bringing them back to us earthly beings. You could get a more extensive treatment of these techniques from the book Generative Programming [2] or from Todd Veldhuisen’s papers [3] but the examples in this book make a very good introduction to the area.

2) Creating a generic library of design patterns using “policy-based” classes eliminate the redundancy found in many systems that utilize Design Patterns.

3) The one line of the book I'd like to (mis?)quote in my review is “Remember, the design constraints buried in the class's design are as bad as magic constants embedded in code”. As obvious as it is, this principle is often overlooked (I know...) and largely because people do not see a solution to it and are willing to live with the “this is as good as it gets” mentality. In this sense the book was a great eye-opener - it showed the feasibility of the solutions and the techniques for the implementation.

Personally, I hope you enjoy the book as much as I did!

References

  1. Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley, ISBN 0-201-63361-2
  2. Generative Programming by Krysztof Czarnecki and Ulrich Eisenecker, Addison-Wesley, ISBN 0-201-30977-7.
  3. www.extreme.indiana.edu/~tveldhui/

Trends

By Reg. Charney

Lock Step

When I started to write this month’s column I was stuck. Nothing much seemed to be happening other than a 10% drop in job openings since last month. What else was I to write about? Chart #1 that shows job openings by platform illustrates my dilemma. It’s the almost the same as last month and the month before that. Was there nothing interesting to say? Then it hit me – all these trend lines should not be moving in lock step. But they are! Notice that around July and August of 2000, Windows 2000 and Windows were bucking the general trend. However, since then, all platform-related skills are showing the same downward trend and amazingly, at about the same rate. Why?

Three hypothesis come to mind. First, in this time of uncertainty, no one is trying anything requiring new skills. Given the decrease in new job demand, this translates into an overall decrease across the board in all job openings. The second possible conclusion is that no new technologies or markets have been opened up in the last six months. Thus, there is nothing to change any of the curves. The third possible conclusion is that I am not measuring the right things and I have missed the really interesting things that have been happening. (See the inset for a possible example.) My preference is for the first conclusion—it’s the economy stupid. However, the second one also bothers me, but only time will tell on that.

As another example of lock step trends, I have included device driver job openings. It is hard to distinguish trend lines for some of the platforms because they are so similar. The one oddity is that Win2K’s curve matches the Unix/Linux curve instead of the expected Windows/WindowsNT curve.

Experience

In my database of 120,000+ openings, only 0.5% specify experience level. The four most popular ranges are:

2-4 years 

 0.03%
1-2 years 0.04%
2-3 years 0.07%
3-5 years 0.12%

Thanks to DICE at www.dice.com for a truly valuable service and allowing me to analyze some of their data.

Disappearing Language

Microsoft may have a problem. I was searching for C#, Microsoft’s new language, on various job sites to see its affect on the job market. However, none of the job sites I searched would accept the # as a valid character. Thus, no one searching for C# would find it. All they would find is C or C++. It’s as if there is no demand for C#.;-)