More precisely, on page 52, column 1, line 6 should be changed from:
typedef MetaNthType<typename TL::Tail, n-1>::Ret Ret;to insert a typename keyword as follows:
typedef typename MetaNthType <typename TL::Tail, n-1>::Ret Ret;On page 53, column 1, near the bottom, the two statements:
typedef typename TypeList <T1, typename MetaList <T2, T3, T4>::Ret> Ret;and:
typedef typename Nil Ret;should be changed to remove the first/only occurrence of the keyword typename.
Bill Rubin
Bill,
Thank you very much for your feedback on my column on typelists. Your bug report is of course absolutely correct. I know it's a lame excuse, but let me say that the reason these errors went undetected is that the Metrowerks compiler processed my erroneous versions without as much as a warning, despite the fact that it is usually fairly strict about the typename keyword. It would be better for me to always compile my code under several compilers. Being a more-than-full-time software developer, however, that's where I draw the line as far as my time is concerned.
I will mention this (and a similar error in a previous column) in the column that I am submitting now. It'll come out in the April 2003 issue, I believe.
Better late than never.
BTW, using typename in:
typedef typename Nil Ret;is of course silly, but I couldn't quite figure out if the Standard actually bans it. Any opinions?
Best,
Thomas Becker
Stephane Grad's article "A Cleanup Framework in C" (November 2002) contains a rather serious flaw. Grad redefines the return keyword with this macro:
#define return \
{_cl_popa(&_cl_cleanup_stack);} \
return
When I see a keyword redefined with a macro, it sends up red flags. Curly brackets in a macro do the same. (I always have to ask: Can I use this macro with an if statement?) Shame on the editors of CUJ for missing these red flags!!!The author presents this sample code:
...
if(!pi)
return FAILED;
PUSHCL(pi,free);
...
Note to CUJ authors: always step through your "trivial" examples with a debugger to be sure they do what you think they do. In this case, the sample code always returns FAILED, because the macro puts an unconditional return after the if statement. OOPS.I don't see a trivial fix for this. The well-known trick of using do{...}while(0) in the macro body fails for void functions or return statements without parentheses. Trying to find a workaround for this has given me a new found respect for the beauty and elegance of destructors.
Regards,
Roger Lathrop
Hello,
Thank you for your comments. The example (function f()) shown in the article is indeed buggy.
The downloadable source code does not suffer from these bugs. I introduced those issues while simplifying and shortening the source code for the article.
I apologize for this inconvenience.
Best regards,
Stephane Grad
CUJ has been doing something that simply makes me mad. An example: the December 2002 issue of CUJ front cover, "A Class for Managing Sockets." Go to Contents on page 3 and try to find an article that has the key words "A Class for Managing Sockets."
On which page do I find "A Class for Managing Sockets"?
Could you please have the person doing Contents on Page 3 look at front cover layout and make sure the key words are in the Contents index.
Thanks,
Hans Wedemeyer
The five-word description of an article on the cover sometimes differs from the article's title. (The reason for the difference is that the cover text and the article title have slightly different goals.) In this case, I agree that we could have given a clearer pointer to the article. We'll watch for that next time.
By the way, "A Class for Managing Sockets" refers to Christopher Rooney's article "A Templated Library for Fast Multiplexing." --jc
I have received the December 2002 issue today and read with interest the comments of Lothar May. I probably share some of his opinions (including those he chose not to voice), as well as some consternation as to the amount of non-C/C++ related material.
It seems eminently sensible that you confine much of your Java content to the bimonthly supplement, Java Solutions (though it seems altogether too thin every other month!), and I was wondering whether CUJ would perhaps consider running an alternative bimonthly on .NET. That way you could probably provide more .NET material than you can now, it is hermetically isolated from the main magazine for the purists, and you could then concentrate on, and give more space to, C/C++ issues. I for one would like to see more C/C++ material, since the language and libraries are getting more complex, not less, as time goes on, and the number of questions is only increasing.
Best regards
Matthew Wilson
Dear Matthew,
Thank you for your suggestion. We received lots of good feedback on our last .NET supplement (September 2002), and we will certainly consider running another .NET supplement in the future.
As I mentioned in my response to Lothar May's letter, C and C++ are the primary focus of this magazine. We will continue to track new developments in the C-syntax languages, and you may see an occasional theme, supplement, or feature article on one of C's proprietary cousins, but standards-based, high-end C and C++ are what we're here for. --jc