Tuesday, February 13, 2007

More C++ links

Danny Kalev, a former member of the C++ standards committee, posts really interesting updates about C++0x (now most likely C++09) on his blog hosted by informit.com. I particularly like this one.

Sunday, February 11, 2007

Service Configurator pattern and singleton deletion

The Service Configurator pattern is about linking in additional functionality in an application dynamically by means of an API such as dlsym/dlopen provided by the OS/run-time linker. Almost all popular platforms provide this functionality. This post is about programmatically, dynamically loaded libraries (hence forth called simply library)(e.g., .DLL, .so) that contain sigletons.

One of my previous posts talks about singleton deletion. If the sinlgleton in such a library is a static instance then it is not deleted untill the library is closed using appropriate API such as dlclose. This can be quite undesirable or awkward at times. All the destruction techniques based on static variables fail if you want to destroy the singleton without unloading the library. A possible variant of the singleton in such a case is given below.

class Singleton {
protected:
Singleton ();
public:
static Singleton *instance () {
if (instance_ == 0)
instance_ = new Singleton;
return instance_;
}
static void operator delete (void *arg) // operator delete is implicitely static
{
::delete arg; // Call the global delete operator.
instance_ = 0; // A very important step.
}
protected:
static Singleton * instance_;
};
Singleton * Singleton::instance_ = 0;

The overloaded delete operator allows us to nullify the static instance_ pointer to the singleton transperantly to the user/owner of the sinlgeton. If the singleton is required again then can be instantiated again. The owner of the singleton can use the const auto_ptr idiom to ensure that the ownership of the singleton is never transferred and it is always deleted.

swap using XOR

In one of my previous posts I described a few ways of swapping two numbers using xor operation in a sinlge line. The discussion is not correct or rather incomplete in the sense that the algorithm needs to be guarded by an if condition. The algorithm that exercises proper care of sequence points is as below:

swap (int &a, int &b) {
if (&a != &b) {
a ^= b;
b ^= a;
a ^= b;
} }

It is crutial that the two number must not be located at the same address. The two numbers must have different identities. The algorithm works even though the values are the same.

Sunday, February 04, 2007

Ownership idioms, The Move Constructor idiom and auto_ptr

There are properties of objects that are relevant beyond mere identity of the object. One of such properties is Ownership! Who owns the object? Can you transfer the ownership? Questions like these become quite important when you are implementing Resource Acquisition Is Initialization (RAII) idiom. Tom Cargill describes [in PLoPD2] a set of ownership patterns: "Creator as a Sole Owner", "Sequence of Owners", and "Shared Ownership". Lets take a look at the idioms for each one of them.

Creator as a sole owner can be simply implemented using const auto_ptr idiom by Hurb Sutter. Sequence of owners come into play when ownerships moves from one guy to the other. (a.k.a. Move Semantics). Standard auto_ptrs use move semantics. Implementation of move semantics appears to be a juicy issue as far as std::auto_ptrs are concerned. See Meyer's errata like notes on his book More Effective C++ and Sutter's GotW #25 articles. M. D. Wilson's article on Move Constructors is a very good start before you jump into Sutter's above mentioned article that has difficulty level 8/10! And Finally, if you are still hungry for some more spicy generic programming stuff, please see Alexandrescu's article on Move Constructor in Dr. Dobb's May 2003 issue.

Cargill's Shared Ownership patterns take us to the world of reference counting and reference linking. Some idioms in this space allow us to avoid making unnecessary deep copies. Copy-on-Write (COW) idiom is an important one. Another idiom to avoid the overhead is called "Temporary Base Class Idiom" given by Bernd Mohr. It somehow reminds me of the move constructor idiom. Finally, Return Value Optimization (RVO) and Named Return Value Optimization (NRVO) are important compiler optimization techniques that avoid unnecessary calls to the copy-constructor and the copy-assignment operator.