Editor's Forum

There are many levels of C++ programmers; all are important and I believe most are productive.

I just finished teaching an introductory course in C++ to freshman CS majors. Not surprisingly, they were excited to understand more deeply the inner workings of objects and algorithms, and I always enjoy explaining the power of object-oriented and generic programming.

On the other extreme, brilliant folks like Andrei Alexandrescu and the many contributors to the Boost libraries [1] continue to enlarge the field of what C++ can do. And if Koenig & Moo’s Accelerated C++ hasn’t already completely put to rest the myth that C++ is not fit for high-level programming, template meta-programming and policy-driven design handily squelch any such lingering nay-saying noise. (Be sure to read Thomas Becker’s excellent article on policy-driven design in this issue).

What of the rest of us in-betweeners? I hope we find ourselves happily sandwiched, picking up wisdom from mentors here at CUJ and elsewhere, and in turn nurturing newbies in our wake.

Let me share a less imposing contribution to the “literature” that recently came my way. The author is well known in the C++ world, but he/she wishes to remain anonymous (therefore I will keep his/her identity along with any revealing comments to myself). In this particular piece, our mystery author, H. P. Typecraft, speaks of names in C++. As you read, be sure to pronounce “std” as a single syllable, somewhat like “stood” (or “stud” for you macho types :-). Enjoy.

The Naming of Types

According To T(ype) S(afe) Eliot
(with apologies to T.S. Eliot and [*] the One Definition Rule)
The Naming of Types is a difficult matter,
        It isn’t just one of your J16 games;
You may think at first that I’m madly ambiguous
        When I tell you, some types may have THREE DIFFERENT NAMES.
First of all, there’s the name that the coders use daily,
        Such as string or ofstream or size_t[] array,
Such as vector or multiset, stack or bad_alloc —
        All of them sensible library names.
There are fancier names if you think they sound sweeter,
        Some for the future, some for today:
Such as std::string, std::vector, std::size_t, std::hash_map —
        But all of them sensible library names.
But an implementer’s type needs a name that’s particular,
        A name that’s peculiar, and more uglified,
Else how can it keep a unique definitional,
        Or spread out its members, or work out its size?
Of names of this kind, I can give you a quorum,
        Such as __void_vector, _FILLALL, or __generate_n,
Such as _CharT or _long__long, or else __hash_map_impl —
        Names that never belong to some user’s type.
But above and beyond there’s still one name left over,
        In namespace unnamed that you never will guess;
The name that no human research can discover—
        But THE COMPILER ITSELF KNOWS, and will never confess.
When you notice a committee in profound meditation,
        The reason, I tell you, is always the same:
Their minds are engaged in a rapt contemplation
        Of the thought, of the fear, of making a “hash” of a name;
                A definable, spellable, nicely incantable
Maybe-overloadable but (had-better-be-)singular[*] Name.
 
— H.P. Typecraft

Note

[1] Boost is a community of top-flight C++ developers and researchers working in open-source fashion to create important libraries for C++, many of which will likely find their way into the next version of Standard C++. We’ll see more on Boost in forthcoming issues.

Chuck Allison
Senior Editor
cda@freshsources.com