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! 🙂
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?
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.
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. 🙂
Long, heated debates, and long, painful agonizing over the choice, often result from “this, or that?”. E.g., return by value or take an in/out argument? The practical answer is often just “yes, both, thank you”, like Winnie the Pooh, and in some cases the practical answer is “a different way”, but for some mysterious reason the practical answer can be very hard to see.