[Note from Terje Slettebø: The origin of this article was a mail I sent to Reg. Charney with some comments and correction to his "C++ Templates" article in the January issue. It wasn't intended for publication, only so that he might correct the article on the web. However, he suggested posting my comments, instead, and first, my letter was more or less unaltered published. As it also contained things irrelevant to the article, I've sent him a suggested new version of this article, given below here, to replace the first version of "C++ Template Corrections"]

I've read your article "C++ Templates" in Overload, February 2003 (reprinted from the ACCU USA website), about the book "C++ Templates: The Complete Guide" by Josuttis and Vandevoorde. I've also read the book, and I have a few comments to the article. In the article, it says (quotes in italic):

Ordering Convention

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).

Actually, in both the second and third typedef, the type is const pointer to int.

In the section in the book where this is found, they make two points, in support of using const after a type, rather than before it (that is int const, rather than const int):

• This way, what is constant is always in front of the const qualifier (such as int const and int * const)
• Textually substituting a typedef with its type gives the same type

The latter case can be shown as follows:

Whereas in the following, it means something different:

typename Keyword

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

I know Josuttis/Vandevoorde recommends this in the book. However, there's not uniform consensus on this issue. There was a discussion about this at the Boost mailing list a while ago, and some points about using class instead of typename were made:

• It's shorter 
• typename may also be used in other parts of a template parameter list, so it may be more difficult to read. This is of course very subjective.

An example of the latter: 

Is this two type parameters? No, it's one type, and one non-type.

Compare this to:

Here, class stands out as the one type parameter.

Partial Specialization

When a template class or function has more than one template parameter, one or more may be specified creating a partially specialized template. 

As I assume you know, partial specialization of function templates is not allowed. However, you may overload function templates, getting much of the same effect as partial specialization. What you are showing in the article is function template overloading.

However, in both cases of class and function templates, there's a partial ordering of the templates, and an overloaded function template may be said to be more specialized than another.

Non-type Template Parameters

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.

Global pointer variables have external linkage (unless made static), so they can be used as template parameters, e.g:

Keyword typename

Generally, prefix all declarations using template parameters with typename.

Just to add to this, this is of course only the case where the declaration is actually a type.

Before I deliver some promised thoughts on the subject of function overloading, particularly for C, I need to correct a think from my last column. I wrote that some unnamed member of J16 invented volatile as a keyword. Of course I meant to write J11. The point being that those two keywords had been introduced by the different languages and adopted by the other one. And now to my topic for this month.

Function overloading is a great idea if used correctly. It allows programmers to provide alternate bodies to functions that depend on the types of the data provided by the arguments. When programmers understand that they come to recognise the essential requirement that overloads need to be contained within a declarative region. Well that is the C++ way of doing. C++ has various added forms of declarative region such as class and namespace scopes. Programmers need to learn to use these in order to avoid gratuitous overloading brought about by simple coincidence of name (e.g. draw applied to a shape and draw applied to a gun.)

Some C++ programmers do not understand the tight binding between overloading and declarative scopes. Without the ability to declare a function other than in global scope overloading becomes a serious menace. A library implementer adds a new function to one of their header files and thereby silently breaks a customers code because it accidentally overloads one of the customer's functions. Though not perfect, namespaces go a long way to dealing with this potential for damage.

C has only two levels at which a function can be declared, global and file. The latter is fine for internal mechanisms that never need to be seen outside the file in which they are used, but mostly functions will be declared at global scope. The limited declarative scopes for functions in C make the C++ overloading mechanism too dangerous to seriously consider. Nonetheless C needs overloading as is demonstrated by the type-generic maths functions that were introduced in the 1999 release of the C Standard.

The problem I have with this is that that mechanism is reserved for use in the Standard C Library and is not extensible to other libraries.

I believe that C needs a mechanism to provide tightly controlled function overloading that is available to all C programmers to use. The idea that I have is to provide a new form of declaration that declares a name as the generic name for a group of functions. Something like:

Now the programmer can call gamma(0.4) and the compiler will recognise that as dgamma(0.4) but if you write gamma(f) (where f is a float variable) it will use fgamma(f).

Obviously we would need to get the exact syntax and constraints right but it seem to me that this would allow C to have a form of overloading without the cost of new declarative regions. We could use this mechanism to solve the const correctness issue that I wrote about last time. I could write:

C already has inline so the body of pstrstr could forward to cstrstr in a very similar way to the C++ solution. From the users perspective it would look like C++ function overloading, but those that want to stick with explicit calls of functions could do so because each function in a generic set would have its own distinct public name.

What do you think? If you do not want Standard's Committees such as WG14 and WG21 to go their own way you need to speak up. Like all groups of individuals, they will come up with some great ideas but they will come up with some real lemons.

Owning Up

The biggest fear that I had before I started writing technically was that of making a mistake and being exposed as a fool. Well, in the years that I have been writing, I have made many mistakes. And perhaps I was a fool – but I gained a lot in spite of my errors. When I did it right, I got known. When I did it wrong, I got to meet and communicate with those who knew better. And in the whole time that I posed my heart at the tip of my pen, I have had a life enriching experience and have met and talked to hundreds, if not thousands, of interesting, fun people. I would never have met them if I did not risk writing for publication. So, while you may risk a lot, I am here to tell you that it is worth it. Take the time and have the courage to write for ACCent or other technical magazines like C Vu, Overload, CUJ, DDJ, or the myriad of other publications. Contact the editors with your articles and ideas. Go ahead – have fun!

In the last issue, I lambasted Intuit for treating their TurboTax customers like criminals. Well, our and others’ comments had some effect. Intuit is now trying to put a positive “spin” on their greed. They paid a company to say that their spyware wasn’t, that writing to reserved areas of the partition table was safe, and the spyware, Macrovision’s SafeCast, didn’t really take up that much in the way of resources. Gee, I don’t know why I don’t believe their paid cronies. Do yourself a favor, just go out and buy H&R Block’s TaxCut.

Now, when business transparency and openness is essential, MS released their latest Destroy your Rights Management (DRM) system. It promotes technology that precludes these virtues and re-enforces MS’s monopoly. Read Ms. Foley’s article (www.microsoft-watch.com/article2/0,4248,903461,00.asp) to gauge the extent of MS’s attempt to protect illegal monopolistic behavior from exposure.

Book Reviews

Agile Software Development Ecosystems by Jim Highsmith, Addison-Wesley, 2002. ISBN: 0-201-76043-6

Agile software development aims for rapidly and responsively producing high quality software, in terms of satisfying a given client’s most important, unpredictably changing, and often incompletely formulated business needs. Compared to traditional methods, agile development involves a much stronger emphasis on flexibility, adaptability, continual collaboration, and low overhead. So which of the several contending agile software development methodologies are really worth investigating or implementing? Is this just the latest hype, the latest repackaging job or is there something new and genuinely valuable here? This book does a good job at answering such questions.

This book describes the leading Agile development theories (their motivating insights and worldviews) and their associated methodologies (which the author somewhat grandiosely calls “ecosystems”). One of the advantages of any wide-ranging survey is the chance to collect lots of interesting highlights (in addition to other things), and the author ably capitalizes on this opportunity. Even if you are already a fan of one of these systems, the wider perspective of this book will probably give you a greater appreciation and understanding of its strengths and weaknesses, and some inkling of what principles and practices you might want to borrow from other systems. This book also features several interesting and sometimes intriguing interviews with the leading proponents of these agile software development systems.

This book is organized in 4 parts: (1) Problems and Solutions (why bother with this stuff, and what can you realistically expect from it) (2) Principles and People (in the sense of people behind the systems), (3) Agile Software Development Ecosystems (the leading ASDEs), and (4) Developing an ASDE (customizing an ASDE to your needs). The ASDEs covered are: Scrum, Dynamic Systems Development Method, Crystal Methods, Feature-Driven Development, Lean Development, Extreme Programming, and Adaptive Software Development.

Even if you aren’t into agile software development systems, you can still find some interesting and useful material. This book is generally well-written and well-edited. The index is good too.

— Conrad Schneiker

I am running an updated versions of the two graphs that I did last month. The signs are there that we have bottomed out and are starting to come back. After the hype and foolishness of the Internet bubble, it is a little comforting to see we exist in a normal, and more predictable industry.

Also, recently, I have been approached with job offers. I believe that it is partly because of my writing and activities in the ACCU. Active involvement with groups like the ACCU increase your networking, skills, and value to potential employers – a word to the wise.