I just read Al Stevens's comments about the keyword typename in his February 2003 DDJ column. It's a nice article, but I thought I could add a few comments of my own.

First, Al's statement, "It's the best I can do given the available literature" may be a bit misleading. In any case, it looks like Al's bookshelf is missing both C++ books I wrote. The first, C++ Solutions (Addison-Wesley, 1997), contains an exhaustive description of when and when not to use typename in C++ source. It does not explain why the keyword is needed, but it does point out cases where you might expect that typename would be okay, and yet it is not.

The second book is C++ Templates: The Complete Guide (Addison-Wesley, 2002), which I wrote with Nico Josuttis. The main discussion on the details of typename is found on page 130 and following. In that chapter, you'll also find a number of other related topics (for example, the use of ::template, .template, and ->template). A shorter discussion is also found on page 44 (part of the tutorial introduction to templates with which the book starts). Aside from this, I'll also mention that it's the best darn C++ book published in the past year ;-)

I do have a few other nits about your article.

You mention the use of typename to refer to member typedefs, but it also applies to member classes and member enums, of course. In the two latter cases, you can use an elaborated name instead. For example, to refer to an enum member E of X<T>, you can write typename X<T>::E or enum X<T>::E. You explain that typename isn't necessary if a compiler doesn't parse a template until instantiation time. That's true, but it might tempt readers into thinking that that is a valid way of implementing Standard C++. In fact, the Standard pretty much requires (implicitly) that templates be parsed in their generic form (see section 10.3 in C++ Templates: The Complete Guide; an explanation would, unfortunately, make this e-mail a bit too long). Currently, only the Edison Design Group's implementation gets this completely right (http://www.edg.com/; I work there ;-). However, historically, Hewlett-Packard's a C++ compiler was the first to parse templates in their generic form and as a result, it was (and still is, I believe) often unforgiving about missing typename keywords (I used to work on the a C++ compiler, too...). Again, our book says a little more about this history.

David ("Daveed") Vandevoorde

[email protected]

More VB Versus the World

Dear DDJ,

In his January 2003 "Letter," Wayne Bloss tries to make out that Visual Basic is the only RAD tool on the market. It is a shame he has never tried Borland's C++ Builder, which can meet his dataset challenge without any code! Delphi provides identical capabilities, backed by Object Pascal; still a far better language than Basic. Tcl, Python, Java, Wx, Qt, and Gtk all have multiple RAD GUI builders with various levels of capability. To the huge markets built from VB, I offer a lemming.

Trevor Davel

[email protected]

RF Band Letter Designations

Dear DDJ,

To the best of my knowledge, the radio frequency "new band" designations listed in Ed Nisley's February 2003 "Embedded Space" column (page 72) have been abandoned, and not all that recently, either. It seems that the "old" designations just refused to go away, so whoever was trying to reinvent the wheel quietly gave up! Reference Data for Engineers, Eighth Edition (Sams Publishing, 1993) provides the following information, quoted from "IEEE Standard Letter Designations for Radar Frequency Bands," IEEE Std 521-1984, reaffirmed 1989.

L 1000-2000 MHz

S 2000-4000 MHz

C 4000-8000 MHz

X 8000-1200 MHz

Ku 12-18 GHz

K 18-27 GHz

Ka 27-40 GHz

V 40-75 GHz

W 75-110 GHz

(1 GHz = 1000 MHz)

Doug McGarrett

[email protected]

Ed responds: Thanks for your note Doug. Although the "new" band letters must have seemed like a good idea at the time, they should serve as a cautionary tale for anyone who thinks changing human behavior is either simple or easy. Joeseph Carr's 1996 Secrets of RF Circuit Design, Second Edition (McGraw-Hill/TAB Electronics, 1997; ISBN 0070116725), presents three tables: pre-1970 military (the "old" letters), post-1970 military (the "new" sequence), and the IEEE Standard, which, predictably, differs from both. Evidently there's a Standard for every occasion!

Happy with XSLT

Dear DDJ,

Thanks to Giuseppe Naccarato for his article "XSLT Querying and XML Documents" because it inspired me to jump into the world of XSLT and start working with a technology I'd heard about but never studied. Using XSLT for dynamic content generation as an alternative to SAX or DOM is tempting.

I also want to suggest an alternative approach to the dynamic assignment of a query in the XSL style sheet. Giuseppe's method requires a lot of I/O and on-the-fly file creation. However, you can use the <xsl:param> element to pass in a query parameter at execution time. For instance:

<xsl:param name="displaySet"/>

<xsl:template match="/">

...

<xsl:for-each select="//employee

[contains(surname, $displaySet)]">

...

</xsl:template>

Then the calling code is:

TransformerFactory factory =

TransformerFactory.newInstance();

Transformer trans =

factory.newTransformer(xslSource);

trans.setParameter("displaySet",

employeeSurname);

trans.transform(_xmlSource,result);

With this approach, all file I/O is avoided. If the query parameter is set to null (or not set at all), then all employees are displayed. The query parameter can easily be applied at the command-line interface, too. The XSLT processor can even support external objects as parameters. I've been able to pass Java objects from one Java resource to another via the XSLT style sheet (at least with a little help from an extension class). Again, thanks for the inspiration.

Jim Hunter

[email protected]

DDJ

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.