Guest Editorial
Those of you who follow the proceedings of the C++ standards committees are probably breathing easier these days. The standardization process now appears to be converging. At the most recent meeting in Monterey last July, committees WG21 and X3J16 adopted no major extensions or changes. Francis Glassborow, of the (very British) Association of C and C++ Users was in attendance as an official observer. Writing in the August issue of Overload, he complained more about his travel arrangements than anything the committees did that week. That has to be a good sign. (Overload is one of the ACCU's publications, and it's a always a fun read. To find out more, contact Dr. Pippa Hennessy at pippa@octopull.demon.co.uk.)Given that the overall framework of the draft C++ Standard is now in place, what's left is falling in the holes, and there are quite a few of them to fill. Nailing down the semantics of new language features is hard enough for the committees, let alone us mere mortals. For example, Scott Meyers, who is not a committee member, recently informed us that his article "Mastering User-Defined Conversion Functions" (CUJ, August 1995) contained a few errors, in spite of his heroic efforts to deliver an accurate interpretation of the draft C++ Standard.
What got him into trouble was one of the newest keywords, explicit. It was devised to take some of the danger out of implicit type conversions. Such conversions happen when, say, you try to pass an object of the wrong type to a function. Would the compiler really let you do that? It might, if you have written a single-argument constructor that looks like it can be used to convert the object to the proper type. If you don't want your constructor involved in such shenanigans, the draft standard now gives you a way to prevent it, by prefacing the constructor declaration with the keyword explicit.
After introducing the keyword explicit, Scott went on to say (p. 59 of the August CUJ) that explicit conversions with such constructors via static_cast or a C-style cast are still permissible. He then provided some examples (p. 60). However, Scott now says, "I believe this may be what the C++ standardization committee intended and the (beta) compiler on which I tested my code accepts this, but a closer reading of the draft standard and further discussion with committee members leads me to conclude that of the three examples I gave, only the last one, Rational s = Rational(1) is allowed according to the current language in the draft standard."
Of course, this is probably all academic. Most compilers on the market don't support explicit, and by the time they do, its definition may change again. Still, we feel it's our duty to correct what appear to be errors (at least, for now) in what we printed. As always, we'll keep you posted on the latest changes to the C and C++ standards. More important, we'll continue to demonstrate practical ways to use these languages today. There is, after all, quite a bit of solid ground under both languages. There's no need for panic. Even so, I can sympathize with those of you who occasionally feel like tearing your hair out. As one who makes a living editing rather than programming, sometimes I'm glad to be on this side of the fence.
Marc Briand
Managing Editor(This is not a palace coup. P.J. Plauger will return to this page next month.)