I sometimes wish that technical magazines would show a little more competence or editorial integrity. A case in point is PC Magazine’s Vol. 19 No. 22 issue article in the PC Tech column that purports to be a “thorough overview of the language that will help C++ programmers make the transition to Web development.”

<RANT>Now, most of you know that I am a language agnostic, but I am not a competence agnostic! If you purport to be a programmer, I hope that you are a good one and make every attempt to improve your skills by reading, studying other people’s code, and being active in professional societies like the ACCU, ACM, IEEE, and other SIGs. All these activities sharpen your skills and make doing your job easier and more fun.</RANT>

Let’s go over the example, Listing #1, used in the article purporting to show the advantages of C#. The three language fragments are in C#, Visual Basic, and C++. They all create a COM+ object, called TrafficLight, set its light to green, and set a timer to 5 seconds before destroying the Traffic–Light object.

There are two minor problems in the example. The C# fragment declares an unused variable, bResult. In the C++ fragment, there is a typo. The reinterpret_cast should read reinterpret_cast<void **>. Both these are probably simple oversights that any writer could make.

From the C# fragment, it would be assumes that exception handling would be used in all cases where it was possible. However, Visual Basic does not have exception handling and for some reason, C++’s exception handling facility is not used. Instead, the older and lengthier convention of testing return codes was used in the C++ fragment. Deduct two points for bad comparisons. The samples should be as consistent as possible when similar functionality exists. Take off a further two points for using exception handling around the parts of the fragment that needs them the least. If these fragments are going to fail, they will do so during creation of the COM+ object, not when the TrafficLight object is set to green or the timer is set.

The next item that raises the question of the author’s knowledge of C++ is his use of pointers. In this simple example, the COM+ object can be defined without the use of pointers at all. Thus, all the lines that read “pMyLight-> …” could be replaced by “MyLight. …”, just like in the C# and VB fragments.

(I am aware that C#, Java and Object Pascal have reference variables that are first class types. C++ references are very restricted. The major difference is that C++’s references must be defined when first declared, and can not be reassigned a value during execution. However, in many cases, either the object name itself or a reference to the object can be used. This example is one of those cases.)

My third criticism is my most serious one. For some reason, in the C# and VB fragments, the TrafficLight object and its constructors and destructors are hidden, but assumed to exist. However, in the C++ fragment, the gruesome details of creating COM+ objects are spelled out inline. Why? No competent C++ programmer would ever write code like this! The assignment of the variable hr would be done in Traffic–Light’s constructor, the call to release() would be done in the destructor. Thus, the C++ code fragment could be written as shown in Listing #2. Notice that the function release() that was suddenly defined only for the C++ fragment is no longer in the main body of code.

For those interested, a simply definition of the C++ class TrafficLight with its constructor and destructor is shown in Listing #3.

I was also bothered by the antiquated use of the #define variable TRUE. Standard C++ has the bool type with the boolean values true and false.

Notice that while we are “forced” in the C++ to use the explicit call to Co–CreateInstance(…), we also able to modify its arguments using default parameters on our TrafficLight constructor—an opportunity that seems to be missing in the C# and VB fragments! (If we are going to be penalized for having them, we might as well take advantage of the opportunity to define our own constructors. ;-))

Lastly, this article and example were about writing for the Web, As such, Java should have been the third language compared, not VB. There seems to be a lack of integrity here. Nowhere did the author say that this article was for those writing only to a Microsoft vision of the Web.

All in all, this was not a “thorough comparison”. Because of the poor quality of the example, it does a disservice to the language that it is promoting.

I wrote the Tech Talk item because I felt the original PC Magazine article showed a lack of integrity, knowledge, or both. At this point, let me make a disclaimer: I am no expert on C# or VB, but I do have a long standing relationship with the C++ community and am a voting member on the ISO/ANSI committee standardizing C++.

C# is Microsoft’s proprietary attempt to break Sun’s stranglehold on the market defined by Java. Claims of C# being an open standard are nonsense. Who is going to gainsay MS doing whatever they want with the language? Will they place the compilers and tools under the GPL? Not a chance. They will be the sole driving force behind C#’s promotion and development. IBM did the same years ago with PL/1. PL/1 was a “better” language than either FORTRAN or COBOL—claims I am not sure can be made of C# against Java or C++. But IBM was the only one who had a say in PL/1’s development. The language died for several reasons: third party vendors didn’t want to compete with IBM in developing PL/1 software; hardware competitors did not want to compete on benchmarks dependent on PL/1; and the initial closed language specifications stifled academic interest. Lastly, a “machine-independent” open system language, called C, took over the market IBM had hoped to gain.

Microsoft would do better bringing their C++ compiler up to standard and letting it produce byte code with extensions that could be ignored by non-MS VM’s and understood by MS’s own.

At this point, Microsoft has less clout than IBM did when it tried to control the market. Unless there are things that I am unaware of, I believe that Microsoft will fail in their C# strategy as an alternative to Java or C++.

Besides, with all the hype about C# and Java, the truly exciting things that are happening to C++ are being overlooked.

By Allan Kelly

Have you noticed how software is becoming more configurable? A few years ago this meant our word processor allowed us to specify a config file on the command line. Now, our word processor comes with thousands of options and it’s own language.

On my old Compaq 286, I had two WordStar versions, a word processing one and one customised for source code. Customising meant running a patch program and carefully changing bytes in the executable.

Now, a little thought shows a clear order of configuration. The simplest programs (utilities) still take arguments on the command line. An application may also look at environment variables and read a configuration file (or registry). These types of programs often provide some GUI way of setting options that are stored in a config file.

More advanced systems allow plug-ins and even have their own API. Here, applications give way to platforms and these often include their own programming languages, not just macro languages.

Often, the more configurable your product, the higher the price tag. Adding API’s, plug-ins and languages means starting a developer community that you must support. Clients will demand consultants to install and configure the product. Your business model will have to provide these services. All this from making your produce more configurable; but then nobody builds a billion dollar company on products that only accept command line parameters.

eXtreme Programming eXplained by Kent Beck, Addison Wesley, 190 Pages, ISBN 0-201-61641-6

This is an introduction to Extreme Programming (XP). It covers XP’s fundamentals and some of its implementation practices.

Extreme Programming (XP) is based on some basic assumptions:

• Individual good practices and results can be pushed to extremes so that the whole is greater than the sum of its parts,
• The XP cost curve differs from the. classic developmental curve in that XP leads to almost a linear cost model that does not increase significantly over time.
• This new cost curve impacts most product development decisions and leads to better software, developed on time and often within costs.

These claims alone make investigating XP worthwhile. However, many sacred cows are killed along the way, so XP is very controversial. Be prepared to question a lot of your assumptions.

The implementation of XP is not that expensive or extreme. In fact, one of its appeals is that it is best practiced in small groups of 3-7 people. This lends itself beautifully to using it on small projects. This is in sharp contrast to many other methodologies that need huge organizations and infrastructures to make them “work”.

The subtitle of the book is “embracing change”. Its definition of this term gives an excellent idea of the style and content of the book: “Embracing change means that the best strategy is the one that preserves the most options while solving your most pressing problems.”

I enjoyed reading this short book and can highly recommend it to you if you are interested in improving the software life cycle process.

It would be nice to say that the trends and changes that have occurred over the last month were heartening, but you already know the things are not getting any better. The question now is: “Are they getting any worse?” Looking at the overall picture as shown in Chart #1, the answer is the it is not improving, but the rate of decline in IT jobs is very small. It is not anything like the drop in the April through September decline. Thus, we are still in a “steady state” situation.

Chart #2 details the rationalized number of jobs related to platforms since the start of the year. From the chart, it is interesting to note that Linux has maintained a higher level of new jobs since January than any other platform. It has also been the least affected by the down turn in demand for platform-related jobs.

There were a plethora of terms found in analyzing the job opening descriptions. For example, Windows terms include 95, NT, CE, Win, WindowsNT, etc. Besides various abbreviations, there are also ambiguous words. Is Win followed by NT to be counted as Windows and Windows NT or just WindowsNT alone? Generally, the “maximum munch” rule is used. That is, the longest recognizable term possible is used. Then there are still the misspellings and unknown words. Thus, all this makes determining what is required fuzzy. Having said that, here are some of the statistics used in the job descriptions:

# job openings	129,000
# unique words	12,200
# unique skill sets	68,800

The five most often used words are:

c++	19951
java	16920
sql	9121
vb	9003
html	8788
javascript	4793

As you would expect with all these terms, skill sets made up of two words would tend to appear more often than skill sets made up of three or more words. The top 5 skill sets were:

frame relay	445
oracle dba	445
c++ java	412
winnt server	361
shell script	361
cisco routers	333

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