Letters to the editor may be sent via email to cujed@cmp.com, or via the postal service to Letters to the Editor, C/C++ Users Journal, 1601 W. 23rd St., Ste 200, Lawrence, KS 66046-2700.
CUJ,
In the July 2002 issue, Bjarne Stroustrup in “C and C++: Siblings” writes about the following program:
main() { printf(“Hello, world\n”); }Stroustrup says: “As a C++98 program, it has two errors. As a C99 program, it has the same two errors, and if those were fixed, the meaning would be subtly different from the identical C++ program.”
I was puzzled by what the subtle difference would be and posted the question to comp.lang.c++.moderated and comp.lang.c.moderated (difference between C++98 and C99). Could the author please explain what the difference is? I’m still looking for the answer and would like to post it to the newsgroups (if I may).
Boris Pulatov
The two errors are:
- The missing int type for main() — because neither C++ nor C99 allows implicit int.
- The lack of inclusion of <stdio.h> to provide a declaration for printf().
I had two “subtleties” in mind when I wrote that sentence:
- In C++, main() cannot be called from within the program, but in C99 it can.
- In C++, main() implicitly returns 0 if you fall through its end.
The reason I didn’t explicitly say what I had in mind was that I wanted people to consider what subtle differences there might be in even trivial examples and how difficult it is to keep all the differences between the dialects of C and C++ straight in your mind.
It appears that I made my point better than I had expected, because I hadn’t noticed that C99 had adopted the C++ rule of implicitly returning 0. Even experts get caught at times. There may be other “subtleties” in this trivial example, but I don’t think so. The key point is that when examples get less trivial, the possibilities for “subtleties” can increase dramatically.
Bjarne Stroustrup
I was most interested to see your articles and focus on delegates and events for C++ in relationship to those of C#. Besides the possibility shown by J. Daniel Smith (“Inside .NET’s Delegates and Events Using C++,” CUJ, September 2002) of providing delegates and events in C++, there are at least two well-known implementations of such a concept for C++ already in existence, which are more complete and more flexible. The first is by Andrei Alexandrescu in his book Modern C++ Design (Addison-Wesley, 2001) in his Loki library, explained in his chapter on “Generalized Functors” and his Loki::Functor class. The other exists in the Boost library’s boost:function and boost::bind implementations. Both of these implementations provide for the definition of a delegate and its event in a declaration of a single instantiated class template and provide for that declaration to encompass an arbitrary return type and a number of arbitrary parameter types. Both provide mechanisms for binding functions, function objects, or member functions to the declaration as a callback.
As an extension to the C++ language using the same accepted double underscore (__) notation as the .NET Managed C++ Extensions, Borland’s C++ Builder has had for over six years a __closure keyword, which provides a supremely easy callback for events, among other uses. In C++ Builder’s __closure implementation, one just assigns the address of any class object’s member function, of the appropriate function signature, to a __closure of that same function signature in order to provide an event callback mechanism. The event handler can subsequently be called at any later time through the __closure pointer. I bring in these examples to illustrate that whether through inventive programming using Standard C++ syntax, or through a language extension, C++ already has the equivalent of the C# delegate/event handling ,and that facility is nothing new to the C++ language implementations.
Eddie Diener
We heard from other readers pointing to alternative approaches, such as the Boost solution. J. Daniel Smith responds, “I failed to mention the Boost library in my closing comments; this was an oversight on my part. However, the focus of my article was to gain a better understanding of C#/.NET-style delegates and events by showing (one way) they could be implemented in Standard C++; making use of the Boost library for this purpose might not have been as elucidating.”
By the way, in case any readers haven’t noticed, we at CUJ are big supporters of the Boost libraries. You’ll find articles on Boost in the April, May, August, and November 2002 issues of CUJ. We hope to continue our support for Boost in 2003. If you have a proposal related to Boost, please send it in. See Andreas Wickner’s letter below for a Boost solution to this question of delegates in events. — jc
Dear CUJ,
In the conclusion of his article “Inside .NET’s Delegates and Events Using C++” (September 2002), J. Daniel Smith mentions that “A more elegant and pure C++ solution might leverage adapters and binders from the Standard C++ library”. In fact, I think it should be noted that using the marvelous tools from the Boost library, everything shown in the article can be reduced to a few simple lines of code. The resulting style also allows for delegating to function objects and simple functions, which makes it in my opinion more flexible than what is offered by .NET delegates and events. An example that loosely follows the example in Mr. Smith’s article is available for download from <www.cuj.com/code>.
Regards,
Andreas Wickner
While reading the first two articles of the C/C++ Users Journal (September 2002), I asked myself many times whether the name of the journal had been changed without me noticing.
I am no “hardcore C++ programmer;” I use Java when speed is not an issue, but I read the C/C++ Users Journal to learn more about C/C++, just like I read a car magazine to find out more about cars.
Given that you wish to inform readers what is going on in the world around us, in my opinion the first two articles were quite worthless from a C++ programmer’s point of view.
I will start with a question: What does the author of the first article (“The .NET Managed Extensions to C++”), Stanley Lippman, wish to tell the reader?
I found the answer at the end of his article (p. 11): “... many of our basic assumptions as C++ programmers are considered bad habits of an obsolete technology that need to be corrected.”
In my opinion, this is the same as telling the readers of a car magazine that “cars endanger the environment and everyone should stop using them.” Do you think that this is wise, even if what is being written is true?
Also, some of the arguments the author points out really annoyed me; for example, on page 8: “[CLR] solves many of the implementation problems of COM.”
Of course it is an option to solve the problems of a library, which has some design flaws (COM) by changing the programming language, but I naturally tend to look for other solutions first.
The second article by J. Daniel Smith (“Inside .NET’s Delegates and Events Using C++,” ends much the same (p. 21): “It sure is easier to add new functionality at the compiler level instead of writing templates.”
Oh well. Maybe it is. Still, this is no reason to do so. Experts should know that the easiest way often turns out not to be the best.
I will stop here. Although I’m angry, I don’t want to insult anyone. I just hope that the next issue of the C/C++ Users Journal will again provide only valuable information for C/C++ developers.
Best regards,
Lothar May
Dear Lothar:
Although our primary focus is on C and C++, we try to keep pace with developments in programming as it is actually practiced by our readers. We view Java, Managed C++, and C# also in the “C family of languages” — they all share a C-based syntax and have evolved ultimately from C. These languages also affect a large number of developers (no matter the reason). We will continue to focus mainly on C and C++, but we would consider ourselves uninformed and remiss if we did not track developments in related areas. The attention to .NET in the September issue reflects the fact that September was our “C# and .NET” issue. Other issues will focus on different themes.
As far as your first reference to Stanley Lippman’s article, it is best to keep the quotation in its context: “The truth is that, in this managed Oz, many of our basic assumptions are considered bad habits of an obsolete technology that need to be corrected. (That is putting it in very stark terms.) If the native Kansas is our home, with shared beliefs and specialized support for the environment, then we are strangers in this strange, Oz-like land of the CLR.”
Because CUJ is published in the real Kansas, as you can imagine, we have all heard far too many Oz analogies; however, since we started into this one, it is worth pointing out that the author is saying the assumptions of C/C++ are considered bad habits only within the strange, mysterious environment of .NET. Note also that these habits are “considered” bad, not that they are bad. It is also worth remembering that Oz, though dreamlike and wondrous, was not a particularly hospitable place and certainly wasn’t for everybody. Dorothy, for instance, didn’t like it and wanted to go home. The author is not intending to repudiate C++ but to offer a warning to those who wish to travel through .NET with C++ as a roadmap. — jc