Letters to the editor may be sent via email to [email protected], or via the postal service to Letters to the Editor, C/C++ Users Journal, 1601 W. 23rd St., Ste 200, Lawrence, KS 66046-2700.
Dear C/C++ Users Journal,
Thank you for your efforts to give us the best information. I am a recent subscriber (I have received four issues) and wish to express my complete satisfaction with what I have received.
Thanks especially for remembering Linux and GTK+. A substantial number of programmers are migrating there, and I believe the number will increase sharply.
For your demographics, I program for a radio station (automation, recording and playback from satellite, news cuts, music playlists, etc). Thanks again for an outstanding product.
George Vacca
Dear CUJ,
I have read Andrew Koenig and Barbara E. Moo’s article “C++ Made Easier: Naming Unknown Types” (February 2002) with great interest. However, the authors discussed only solutions that already exist as an extension or as a part of the language, and these still leave much to be desired. Therefore I returned to my favorite pet idea for a core language extension: a keyword for an unknown type. It would work exactly like the typeof extension, but without taking any parameters, so one could consider this new keyword to be just a syntactic sugar on typeof operator. In this letter, I will name this imaginary keyword: unknowntype. This doesn’t mean that I’m necessarily proposing that particular keyword since we could as well reuse typename (my personal favorite) or use typeof without parameters or find some better match. To illustrate what the proposed keyword would do, let me start with an example from the article:
template<class T> void process(T& v) { // ... }
In the body of the template function, instead of writing:
typeof(v[i]) vi = v[i];
or
T::value_type vi = v[i];
we would write:
unknowntype vi = v[i];
because all we really care is that the type of vi corresponds to v[i]. We don’t want to have to write things twice (and we have to with typeof) nor should we rely on a convention (a good thing convention, but one can’t always use it, and it also increases the amount of necessary knowledge to start writing code). The compiler knows what type is returned by v[i], and therefore we are using that knowledge to our advantage. Notice that all this doesn’t diminish the type safety since the unknowntype of vi is known at compile type (just as it is known for typeof(vi[i]) and T::value_type), and vi can be further used only as an object of that particular type.
The previous example is rather simple, so advantage is not enough to warrant a core language extension. However, consider this example (adapted slightly from The C++ Standard Library: A Tutorial and Reference by Nicolai M. Josuttis, page 306):
pos = find_if(coll.begin(), coll.end(), std::not1(std::bind2nd(std::modulus<int>(),2)));
Imagine that we want to make a variable of the type returned by the std::not1(std::bind2nd(std::modulus<int>(),2)) expression for further reuse. We would have to write:
typeof(std::not1(std::bind2nd(std::modulus<int>(),2))) f = std::not1(std::bind2nd(std::modulus<int>(),2));
or (after finding out what is the exact type returned by the expression):
std::unary_negate<std::binder2nd<std::modulus<int> > > f = std::not1(std::bind2nd(std::modulus<int>(),2));
In my opinion, typing:
unknowntype f = std::not1(std::bind2nd(std::modulus<int>(),2));
is more appealing and the meaning is clearer. Not to mention the advantage of what would happen if the type returned by the expression changed tomorrow.
Of course, typing:
unknowntype f;
would raise a compile-time error since in that case the compiler wouldn’t be able to deduce the real type of f.
As our knowledge of generic programming is growing, complex usage patterns are increasing in number, and I think that this new keyword would make writing and maintenance of generic code much easier. As I stated previously, this proposal could be considered just as syntactic sugar on typeof operator. While I think that having standard typeof is a very good thing and would be a step forward in the right direction, the additional advantage of not having to write duplicate code and the simplicity to expressions that this proposal brings, could be, in my opinion, a step forward in making C++ easier to understand and write.
Finally, since the proposal is so straightforward, I’m certain that I’m not the first one to come up with it, so my question is this: why not this extension and what would be its negative consequences?
Best regards,
Ivan Erceg
[email protected]
Dear Ivan Erceg,
You suggest the following.
In the body of the template function, instead of writing:
typeof(v[i]) vi = v[i];
or
T::value_type vi = v[i];
we would write:
unknowntype vi = v[i];
because all we really care is that the type of vi corresponds to v[i].
I completely agree with your suggestion and think it would be very nice indeed if C++ had such a feature. Unfortunately, one case in which it would be particularly useful is also very hard to implement. Consider this function:
unknowntype abs(const unknowntype& x) { if (x < 0) x = -x; return x; }
In this form, this function is similar in effect to:
template <class T> T abs(const T& x) { if (x < 0) x = -x; return x; }
because in both cases, it is possible to determine from inspection that the return type is the same as the argument type. However, consider what happens in the presence of separate compilation. It is possible to examine the declaration:
template<class T> T abs(const T&);
and figure out the return type from the argument type. However, it is not possible to do so with:
anytype abs(const anytype&);
Now, the function declaration no longer contains any clue as to the relationship between the argument and result types. As a result, implementation becomes much more difficult.
Because of this difficulty, a facility such as anytype might not find its way into a future revision of the C++ Standard as readily as you or I might like. In any event, our best course right now is to use the same conventions as the standard library when we have the opportunity to do so — and that was the point of our article.
Regards,
Andrew Koenig
Hello,
The June issue of the C/C++ Users Journal certainly is interesting. Keep up the good work.
The reference at the end of the article, “A Multiple Substring Search Algorithm,” by Moishe Halibard and Moshe Rubin (June 2002) to <www.dir.univ-rouen.fr/~charras/string/string.html> does not work. Do you know of an accurate URL?
Charles Elliott
Charles,
Thank you very much for your kind words about our recent article in CUJ.
We apologize for the fact that the URL referenced at the end of the article is no longer available. Although the bad link is referenced from scores of sites on the Web, the site together with the content was removed without notice.
Fortunately, we have since found that Christian Charras and others have reopened a newer and very impressive site: <www-igm.univ-mlv.fr/~lecroq/string/index.html>. This site not only carries all the content of the previous one, but each algorithm now has a Java applet that shows the algorithm in action. We’re convinced you will find the site very informative.
We thank you again for your email and apologize for the inconvenience.
Moshe Rubin and Moishe Halibard
Alchemedia Ltd.
<www.alchemedia.com>
I thoroughly enjoyed Mark Bucci’s article, “Using Genetic Algorithms” in the June 2002 issue of CUJ. I was struck by two important details concerning his evolutionary analogy.
First, his genetic algorithm required the concerted intervention of a creator. I don’t know of any cases of computers spontaneously spawning useful programs.
Second, although his algorithm was very clever at producing micro evolution, or adaptation as it is commonly called, it never evolved into an entirely different species, providing solutions for problems other than its designed purpose, thus failing to demonstrate macro evolution.
I think his article was a prime example of intelligent design.
Dear CUJ,
Recently I read a great article “Sutter’s Mill: Why Not Specialize Function Templates?” by Herb Sutter, July 2001. This is really one of beautiful matters.
One thing I noticed though is that example 2.c says:
// (c) explicit specialization of (b), // because the signature can match // either base template and (b) is // more specialized than (a) template<> void f<int*>(int*); //
This is not correct because that is exactly the specialization of (a) and not (b). The specialization of (b) will be:
template<> void f<int>(int*); // T == int !
Therefore the last line in this example calls (b) and not (c).
The code in examples 2 and 3 differs only in the order of template declaration. The author implies that specialization depends on that order. Actually both specializations in both examples are exactly the same (specialization of (a)).
If we want to make the difference, then we have to force the compiler to deduce template argument from function argument. For example,
template<> void f(int*);
However the Standard (14.7.3.12) says that this specialization is ambiguous if it comes after:
template<class T> void f(T); template<class T> void f(T*);
So we also will need to change the order of declarations in example 2, first in the (b) declaration, then (c), and then (a).
Thank you,
Oleg Mazonka, Ph.D.
Software Engineer Motorola
Hi Oleg,
Thanks for your mail. The bugs you note are corrected in the version posted online at <www.gotw.ca/publications/mill17.htm>.
I’m glad you enjoyed the article!
Best wishes,
Herb Sutter
