Before even getting into the introduction for this article, here is some news that might be of interest to you.
A while ago, Jonathan H. Lundquist and Mat Marcus independently ported parts of Loki to Visual C++ 6. Their implementations were meant as a proof of concept and did not reach completeness. By and large, due to various compiler related problems, at this point in time Loki is more of a source of inspiration for people’s designs, rather than a “shrink wrapped” product that you just drop in your program. The typical Loki user is a savvy, brave developer who doesn’t hide under the desk at the sight of an error message even when that message’s length might “buffer overrun” some Web servers.
It came as no little surprise to me when Rani Sharoni emailed a complete, unabridged port of Loki to Visual C++ 7.0 (sic!).
If you use that compiler, you may want to give Loki’s port a whirl .
Other related news there’s an ongoing action to port Loki to Boost, a move that would unite two efforts into a convergent one. Loki::SmartPtr is on its way already; as always when it comes to smart pointers, there’s much discussion, this time of unprecedented productivity. Also, Joe Swatosh has proposed the mightily popular ScopeGuard , written by Petru Marginean and yours truly, for inclusion into Boost as well.
In a word, these are heady times for cool C++ work. Ultimately, this means you’ll have less grunt work to do and more time to spend on your high level design.
In the past two installments of “Generic,” we defined discriminated unions and defined a core Variant class. That core class offers the most basic facilities that allow its user to store an object into the Variant, query the type of an object inside a Variant, and retrieve that object in a type safe manner. Moreover, Variant is portable and has quite an efficient foundation.
This is hardly an exciting collection of features. Sure, portability is a good thing. (But then, what’s porting good for, if you have to deal with older, nonconforming compilers?) Also, efficiency certainly doesn’t hurt. But these are not features by themselves Variant’s portability and efficiency doesn’t render it more expressive when you write code using it. The thing is, more features would be very helpful. Today, we will focus on adding a number of powerful features to Variant some that don’t exist within similar implementations.
But before getting into that, you are due for a soapbox.
Finally, It Happened And It Will Happen Again
It is a fact of life that no matter how hard you try you cannot please everybody. That’s why, ever since Modern C++ Design  hit the shelves, I’ve been waiting for the “your book stinks” message. No doubt, it was to come sooner or later. Damocles’ sword has been hanging for more than one year now, when finally it fell, in the form of a review on Amazon.
According to that review, Modern C++ Design is “typical highbrow snobbery, academic extremism by (and for) tenured people who do no actual work and must squeeze out of themselves a piece of writing for the C++ Report on a monthly basis.” That’s quite a comprehensive statement that covers both me, who wrote what you’re reading right now,
and yourself, because you’re reading it. Maybe we should both stop right now.
Or maybe not. If anything, I would have hoped for a more based “your book stinks” message; this is too easy to combat.
Second and this reveals why I’m bringing the whole thing up I don’t really feel being squeezed after writing any of the bimonthly installments of “Generic.” There is, however, an issue that I wanted to ask your opinion on. (If you also add the new book that Herb Sutter and myself are writing, C++ Coding Standards, things get really depressing.)
The return of C++ is not a sequel to Modern C++ Design. Sequels can be bad, especially when they are a rehash of a successful idea, in lack of inspiration for something genuinely new. Also, what I don’t want this new book to be is a regurgitation of my own articles. I believe that if you pay money to buy a book, then you deserve more than bound material that could be found online gratis.
This ultimately means it’s not the flow of new ideas that’s at stake, but a conflict of interests. When something cool comes up, the tough decision is, should this be part of a new article, or part of the upcoming book? That’s what’s stopping me from writing about some exciting things, such as Design by Contract, generic implementations of the Observer pattern, composite objects, or a complete treatment of error handling in C++.
In essence, if you have any idea on how to address this conflict of interests, don’t hesitate to email me.
Fortunately, there are many cool new ideas floating around as well, for which the article form is the most suitable. For example, you’ll soon see how generic sorting and searching in C++ are not quite top notch yet, and how to achieve much better performance than many current library implementations offer. Given that programs spend about 80% of time searching (when they don’t do I/O), you should have a 0.8 degree of interest in that article. When you don’t do I/O, that is.
Enough about that. Otherwise, it’s only more fuel to say, “Aha! No more inspiration, so here’s some of this guy’s existential angst for us to solve!” The thing is, good long term programming columnists such as Al Stevens, Michael Swaine, or our dear Bobby Schmidt, do include soapboxes in their columns. And you know what? I love reading them. In proportion, it’s like reading Russian novelists: it’s not something sensational they’re saying, but you simply can’t let it slip out of your hand.
Let’s recap quickly where we were with our Variant implementation, with a couple of code examples.
Variant object is an object that can store exactly one object of a collection of types. Grace to a constructor,
you can directly initialize a Variant with an object of one of those types. For example: