How often have you declared a variable and invented an ungrokkable three-letter name for that variable, just to temporarily hold the result of some API function so that you can check it immediately after the call? Let me guess, you’ve done that thousands of times. And if so then here are happy tidings: you can completely avoid introducing all those helper variables! :-)
Evidently some people get to my blog by googling up C4099, the MSVC warning that you’ve used
struct in one place and
class in another place, for the same class. This is one of the alleged sillywarnings in my sillywarnings suppression header. But given e.g. the discussion at StackOverflow, is it really a sillywarning, or perhaps something to take seriously?
In part I I showed how to use the cppx library’s exception translation support, which decouples the specification of how non-standard exceptions should be translated, from each routine’s invocation of such translation. The translation can be customized by dynamically installing and uninstalling exception translator routines. And essentially each routine that wants exception translation must use a
catch (this will most often be a generic
catch(...)) where it invokes
cppx::rethrowAsStdX, which in turn invokes the installed exception translator routines and performs a default translation if none of them apply.
In this second part I discuss how that translation machinery works.
In part III I’ll discuss the support for installation and uninstallation of exception translator routines. And perhaps I’ll need a part IV to discuss the cppx exception types! Anyway, now, diving down into the code…
MFC throws pointers, Xerces throws various types not derived from
std::exception, and as I recall the Lotus Notes API throws integers. An interesting diversity. But as the Chinese curse goes: may you live in interesting times! Such non-standard exceptions generally require you to have multiple
catches every place such an exception could otherwise escape to higher levels, or where you want to handle any exception with a given general meaning. It’s not that the designers have tried to be clever or that they’re out to get you: it’s just that these libraries stem from before C++ was standardized, i.e., before 1998.
One partial remedy is exception translation. Somehow arrange for any non-standard exception to be caught and result in some corresponding exception derived from
std::exception. It does not solve all the problems – but it sure beats doing it by copy-n’-paste coding of exception handlers!
With C++98 exception translation cannot be completely centralized in a portable, reusable way. As far as I know that’s not possible even with the upcoming C++0x standard. But it’s possible to provide portable and application-independent support that does most of the job, and that provides a general convention that largely eliminates the chance of any non-standard exception slipping through, and that’s what I discuss here. [… More] Read all of this posting →
Like my posting about cloning this posting about unique identifier values is in preparation for discussing the cppx library’s exception translation support. In short the aspect discussed here is how to let the calling code choose an id for a set of installed translators, so that it can remove them all in one operation (specifying that id). And the simplest id you have in C++ is a type with external linkage. You can obtain a unique-wrt.-comparisions id for a class from the
typeid operator. The only problem is that that id, of type
std::type_info, is not copyable and not generally comparable, so it can’t be used directly as a key in a
std::map, say, and the standard fails to guarantee that you will always obtain the same
std::type_info instance for the same type, so it’s a bit risky to use a pointer to that instance…
To clone an object is to create a dynamically allocated copy of the object, of the same dynamic type, generally without knowing the exact dynamic type. The common way to do that is a virtual method, e.g. called
clone, that simply invokes the type’s copy constructor. And the main problem with cloning in C++ is: how to reduce the extreme redundancy of zillions of essentially identical
clone methods everywhere?
ZStr ownerhip transferring string class that I introduced in my first Xerces posting may have seemed like total overkill for the job. In C++98 it’s difficult to do correctly, and it requires some less-than-commonly available support machinery. And so if Xerces string handling was the only reason to do it, I wouldn’t have done it.
But once a string class like
ZStr is available you (or at least I) find that it’s a natural first choice for many tasks. The beauty of it is that it allows you to defer the decision of trading efficiency for functionality, because the ownership can be transferred to an immutable sharing string type at any point. Or the string can be copied to a copying mutable string type like
With a type like
ZStr, if you’re implementing library-like functionality, the decision of which “rich” string type does not have to be imposed on the client code. Instead of already trading away the efficiency you’re giving the client code the choice, including the choice of just using
In part I of this series I discussed Xerces’ UTF16-based string representation, a common deallocation pitfall for such strings, and how to convert to and from such strings correctly by using C++ RAII techniques. For the RAII techniques I presented one solution using
boost::shared_ptr, and one more efficient solution using a home-brewed ownership transfer class,
cppx::Ownership. And I promised to next (i.e. in this installment) discuss how to do it even more efficiently by using
wchar_t strings as the program’s native strings, and detecting the minimal amount of work needed for each conversion.
For Windows, where
wchar_t corresponds in size and encoding to Xerces’
XMLCh, all that’s needed to convert from a
wchar_t literal to Xerces
XMLCh string is, at most, a little
reinterpret_cast… But that won’t work on a system with 4 byte
wchar_t or a system where
wchar_t doesn’t imply Unicode. And although the non-Unicode systems are perhaps not your top porting priority, 4 byte
wchar_t systems are common.
The wrapping that I start discussing in this posting, based on the cppx
Ownership class, does a simple
reinterpret_cast when it can (e.g. for a literal
wchar_t string argument in Windows), and a dynamic allocation plus transcoding in other cases.
Ownership wrapping of the result abstracts away the details of how the string is converted, and whether deallocation is needed. Thus, the calling code does not have to care. It gets raw null-operation efficiency where possible, and otherwise at least the same convenient notation + C++ RAII based safety. :-)
Ownership class is like
std::auto_ptr with custom deleter and without implicit pointer conversions. In my next posting I’ll show how to use it to simplify dealing with Xerces strings, in an efficient way. It’s also convenient for many other things. :-)