If you’re already familiar with casting to inaccessible base, disambiguation casts, casting to most derived object, casting to/from first member of a POD, and accessing the built-in address operator via a cast, then this blog entry is perhaps not for you. 🙂 It’s basics, but for some reason even seasoned C++ programmers are not always aware of all these special cast operations. This is about special case semantics, not syntax or general operations.
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?
[Latest, as of 10th June, just a few hours after posting: Oops, while the stats probably are somewhat broken, this purported “proof” is a mis-interpretation (and that could apply also to my earlier observation): the stats main page only shows the 10 most viewed pages. Argh. Is it better to add a comment like this, showing off my rush-to-conclusions error to all readers, or to silently delete the posting? I left the posting in place. In a way, my eror ilustrats my point that its extremely easy to make errors, especially based on invalid assumptions!]
In my earlier posting “wordpress: broken stats?” I conjectured that the WordPress number-of-views-of-your-blog stats are broken. I then found an instance where the number of views of a posting decreased from 1 to 0 (within the same day), but that’s a bit difficult to show visually! However, right now the stats of this blog offer self-contradicting information in the same page, so I took a snapshot of the screen: [… More] Read all of this posting →
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.
My original posting on how to avoid MSVC sillywarnings seemed to be quite popular. I’ve now added suppression of two more sillywarnings. The first of these is so braindead as to be almost unbelievable, it’s like it’s directly from the Department of Dumb: for the example below the compiler first (incorrectly) warns that type
S “can never be instantiated”, and then it (correctly) goes on to instantiate it…
Roger Penrose is the Rouse Ball Professor of Mathematics at the University of Oxford. E.g. he’s the inventor of Penrose Tiles, which can cover a plane but only aperiodically (nice effect!). And he has proved, rigorously!, that you are smarter than him. Or, to be ultra-precise, he has proved that there are Mathematical Truths™ that you can easily see but he cannot. In this posting I shamelessly reproduce his proof.
You thought it would be safe to post an article to [comp.lang.c++.moderated] using the
X-Replace-Address header (or line within the article). No spam, since in the posted article the address will appear as
firstname.lastname@example.org. 🙂 Hah!
My mom’s 75 years tomorrow, and is visiting. Not much time for blogging or programming then, so, sorry, this blog has been left untended.
Assuming the WordPress stats bear some semblance to reality this is apparently subtly reflected in the number of views of the blog. It’s gone up and down almost as usual. But:
when I remove all the peak values then what’s left has until now been ∪ shapes. But the last few day a ∩ shape (although just one single instance) has emerged. That is, the second derivative, the rate of change of the rate of change of number of views, suddenly changed!
I know, one data point is perhaps too little to generalize from, but it looks like the so called “visitor pattern” at work: when your mom visits, the second derivative of the number of views of your blog may change!
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. 🙂