1. When working with incomplete types. Classic example is when implementing the Pimpl idiom.
2. When we want our class to be copyable and the member object is of a non-copyable class.
3. When making a member out of a class that does not have a default constructor.

To elaborate on the second point, the copy construction and copy assignment of a class usually involves copying/assigning the parent classes and then the members. This is what the compiler would do with the implicit copy constructor and copy assignment operator. But even if we implement it ourselves, it should almost always be constructing/assigning parents and members, and in that order. If the members are of a non-copyable class, then this means that the class that we define also becomes non-copyable.

To elaborate on the third point, if we make use of an object member out of a class that does not have a default constructor, then, while constructing our class, we have to make sure that we call the appropriate constructor for the member with appropriate arguments. This can get a bit restrictive especially with templates:

template <typename T>
class CustomClass1 {
private:
    T data_;
...
};

CustomClass1 can only be specialized with types that have default constructors. Instead, CustomClass2 below can be specialized for any type:

template <typename T>
class CustomClass2 {
private:
    T* pData_;
...
};

As an aside, two things to keep in mind when defining classes with pointer-to-object members:

• It is probably a good idea to make use of boost::scoped_ptr or boost::shared_ptr instead of raw pointers, so that deletion is handled automatically.
• Always remember to provide one’s own declarations (with or without definitions) of the copy constructor and copy assignment operator for the class that has pointer-to-object members, as, the implicitly generated ones almost certainly will not be what we want (and can very likely be dangerous). Note that if we used a scoped_ptr, this is automatically taken care of, because, as indicated in point 2 above, since scoped_ptr is a non-copyable class, the enclosing class itself becomes non-copyable (unless you intentionally make it copyable and deal with non-copyable members somehow).

Now, I guess the other way to look at point 3 is to always provide a default constructor for a class unless it absolutely does not make sense. It helps in many ways:

1. It alleviates the restriction of having to keep pointer members (if this were the only reason, like in point 3 above).
2. You can create dynamic arrays as follows, only if there is a default constructor:

CustomClass* dynamic_array = new CustomClass[20]; //only possible if CustomClass has a default constructor.

//For static arrays you could invoke parametrized constructors using the initialization syntax, provided there is an accessible copy constructor:
CustomClass static_array[20]; //only possible with default constructors.
CustomClass static_array_param[2] = { CustomClass(...), CustomClass(...) }; //parametrized constructors invoked.

//Similarly for container classes. Following vector works with parametrized constructors provided there is an accessible copy constructor (which is a must for elements in a vector anyway):
std::vector<CustomClass> v(10, CustomClass(...));

// But notice that, strictly speaking, you are creating temporary object(s) with the parametrized constructor and then copy-constructing the elements in the static array or vector using the temporaries.

Interestingly, many standard library classes provide default constructors although it might appear to not make much sense.

#include <fstream>

ofstream file1("/tmp/tempfile"); //parametrized constructor makes sense.

//However, we can achieve the same effect with the following:
ofstream file2; //default constructor.
//Nothing constructive you can do with file2 until you call the open method:
file2.open("/tmp/tempfile");
...

Updates:
1. Corrections in the section about default constructors, with regard to static arrays and vectors.

2. Reference: http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.5

3. Reference: http://www.acm.org/crossroads/xrds1-4/ovp.html

void swap1(int& a, int& b)
{
    a = a^b;
    b = a^b;
    a = a^b;
}

… that is not there in swap2() below?

void swap2(int& a, int& b)
{
    int t = a;
    a = b;
    b = t;
}

Learned it the hard way. My Quicksort program was misbehaving and it was a bit puzzling until I figured out that the bug was in my swap function. The bug surfaces when you try to swap a variable with itself – you’d want it to remain unchanged, but swap1() will zero it out.

In a related note, Bjarne Stroustrup wrote (and I quote from here):

if (this == &a) return;  		// beware of s=s;

:)

Recently, faced with a decision problem, I started off with an approach that used Dynamic Programming (DP, here onwards) – because it appeared deceivingly similar to those classic DP problems, you know, matrices and all, and I was a bit over-enthusiastic. The problem basically turned out to be the decision version of the Pathfinding problem – to determine whether there exists a path between given two nodes u,v .

Although I switched to a ‘better’ algorithm, which still solved the optimization problem (Dijkstra’s shortest path algorithm) and therefore did feel like an overkill, I realized later that all I needed to do was determine whether u and v belonged to the same connected component of the graph, and thus a simple Depth First Search would have sufficed.

In retrospect, my first thought was that I had made the mistake of trying to solve a decision problem using dynamic programming, that I had overlooked the fact that DP should be applied only to optimization problems. But then it got me wondering – how come finding the n^th Fibonacci number, which is not an optimization problem, is something you can solve effectively using DP? (On a side note, this also brought my attention to the type of computational problems – decision, search, optimization, counting, promise. I guess Fibonacci would be a search problem?)

So the whole thing got me asking myself two questions:

1. Do the problems for which DP is applicable, necessarily be optimization problems? The requirements for DP are that the problem exhibit optimal substructure and subproblem overlap. Fibonacci is big on overlap, and exhibits optimal substructure trivially (later Fibonacci numbers are based on previous ones). But does that make Fibonacci an optimization problem in some twisted way?
2. Can a decision problem be converted to an optimization problem of equal hardness? Every optimization problem has an associated decision problem, which is usually easier, so I’m talking about whether there is one of equal hardness – meaning solving one is equivalent to solving the other). Or does it even not make sense? In my first approach of trying to solve the problem using DP, I was in some way trying to convert the decision problem into an optimization problem (marking distances as ∞ if no edge existed between two nodes and thus trying to see if my dynamic programming ‘equation’ that tries to optimize something, would trivially avoid those edges and so on). Question is, could I have succeeded by taking that route at all?

The way I had learned it (and I’m sure there are many others out there) is that

you qualify a method as const if you don’t want the function to modify any members.

And then they tell you about mutable member variables and how const methods can modify them.

For a language feature, this was not quite convincing or at least compelling enough for me. I mean, the use case was pretty much similar to declaring a local variable that is never passed around in function calls, a const. It just safeguards you from accidentally modifying the variable yourself and is therefore a may-have. Don’t get me wrong, I totally agree that this aspect is definitely good programming practice and even sometimes lets the compiler generate better optimized code. But come on, this is perhaps not why const was introduced in the first place (remember that const keyword is one of those things that originated in C++ and then went onto C).

const really comes in handy when variables are passed around in functions and when APIs are defined. Like when you make the ‘source’ argument of strncpy() a const,

• so the caller can pass in a source string that is const, and
• so the caller is given a guarantee that the call is not going to modify its source.

These, I believe, are the ‘real’ uses of const (in the current context).

Which is why it made my day when I finally came to understand that

you make a method const so it can be invoked on const objects.

and

you make a method const to guarantee the client of your class that calling that method will not change the ‘state’ of the object.

And that made complete sense! And that is when you really appreciate why the mutable keyword is there. Because, even for constant objects, you might want certain methods to modify members that don’t really affect the ‘state’ of the object (mutable keyword was in fact added later when this need quickly became obvious). In fact, wouldn’t you say that the very presence of the mutable keyword validates the point of this post?

And then on, it all made sense – why you must make methods const whenever you can, why you can have overloaded methods based on just them being const or not and so on.

Although nothing original from my side, let me wrap this post up with a typical example scenario where you absolutely need a const method (this is straight out of Effective C++): Let’s say we are designing a class Array that simulates a regular array but also does bounds checking, and can be used like this:

Array<int> a(4, 7); //creates an Array of 4 ints,
                    //all initialized to 7.
const Array<int> ca(4, 8); //creates a const Array of 4 ints,
                           //all initialized to 8.
...
a[2] = ca[3]; //OK.
ca[2] = a[3]; //compile error!
...

And the way this can be achieved is by overloading the array operator [] twice – once as a non-const method which will get invoked for non-const objects, and as a const method which will get invoked for const objects, as follows:

template<typename T>
class Array
{
public:

    ...

    //For non-const objects:
    T& operator[](const size_t i)
    {
        // If i is out of bounds, handle error - throw.

        return v_[i];
    }

    //For const objects:
    const T& operator[](const size_t i) const
    {
        // If is out of bounds, handle error - throw.

        return v_[i];
    }

    ...

private:
    vector<T> v_;
}

I wish I could learn everything right the first time…

1. The ‘Default’ in a ‘Default Constructor’, refers to the parameter list, and that too in the call. Basically, a default constructor is a constructor that can be called with no arguments. So a constructor is a default constructor if it does not take any arguments or it takes default values for all its parameters – irrespective of whether you’ve explicitly defined one or the compiler generated one for you.

2. … which is why there is no such thing as a Default Copy Constructor. I believe there are mainly two kinds of C++ folks out there – those that use the term ‘default copy constructor’, and those that used to use this term and now refrain from it. The whole problem is one tends to think of ‘Default’ in this context to refer to ‘one that compiler generates by default if you don’t provide one’. It naturally follows from point #1 above that one can’t have the copy constructor called without any arguments, so there is no such thing. Unfortunately, this has become sort of a standard usage, even in some books (just do a google search and you’ll know). But you wouldn’t see Stroustrup or Meyers use this term, so that should be enough reason to refrain from it. I prefer the term ‘compiler-generated’ instead – ‘Compiler-generated copy constructors’ and ‘Compiler-generated default constructors’.

3. Another mistake we all make at some point or the other, and we hear others make almost all the time, is the following innocuous looking statement: ‘the compiler-generated copy constructor does a bit-wise copy of its members’. Correct? No! And it’s one of those things that you quickly realize is wrong when you are made to think of it, but you learned it wrong because it was passed on to you and you never paused to think about it. The compiler-generated copy constructor does the following:

• Calls the copy constructor of any and all base classes with its input argument, the RHS object reference (so that the base parts are copy-constructed by the base itself).
• Constructs the non-static members by ‘copying’ from the respective members of the RHS object – meaning, for those members that have a copy constructor, the copy constructor is called, and for others, a ‘regular’ copy assignment is done.

4. A copy constructor does not necessarily have to take a const RHS. The signature one usually sees for a copy constructor is the following:

T::T(const T& rhs);

But the following is perfectly valid as well:

T::T(T& rhs);

Of course, it makes sense once you think about it. A classic use of this is in the implementation of std::auto_ptr. The smart pointer philosophy for auto_ptr is to transfer ownership and nullify the RHS in a copy. That is, if you do the following:

...
std::auto_ptr<int> ptr1 = new int;
std::auto_ptr<int> ptr2 = ptr1;
...

the statement at line 03 results in ptr1′s member primitive pointer to int getting set to 0. In order to facilitate this, the copy constructor has to take a non-const reference to the RHS.

–

Updates:

(7th Aug 09): Reg point# 3, check out this entry on Herb Sutter’s GOTW about the order in which subobjects are constructed.

And so it was that, when I read about a certain use of heap in this article on wikipedia, I was enlightened. In particular, it talked about doing a traversal of a heap.

Now, heap traversal is not something you see everyday. How is it interesting? How does it even make sense? Well, imagine the following problem: Given a heap containing n elements, return the k smallest elements from it (not in any specific order).

One way to do it, the first thing that usually comes to mind is to do a removeMin() on the heap k times, which would return the k smallest elements (and in order), in O(k log n) time.

But imagine instead, and herein lies the rub, using the Breadth First Traversal on the heap – but with the exception that, instead of picking an element from the front of the queue that stores the children of elements that we visit, pick the min element and recursively visit that child. In other words, instead of using a queue to store the children of a node when we visit it, use a priority queue.

One can see that using this approach, the BFS traversal turns into a traversal that visits the elements in order of their ‘weights’. Then, coming back to our problem, to get the k smallest elements, we will have to ‘visit’ k times in the traversal, and the priority queue would therefore contain at most k elements (a visit results in 1 element being deleted from and 2 children being added to the priority queue).

If we implement this priority queue, in turn, using another heap, we can then find the k smallest elements in O(k log k) time, as the second heap would contain at most k elements at any time. With an additional space requirement of O(k), of course.

So, for instance, to find the top log n elements from a heap containing n elements, one could do it in O(log²n) time using the first approach, but in O(log n log log n) time using the second.

Now, is that awesome or what? :)

qsort' :: (Ord a) => [a] -> [a]
qsort' [] = []
qsort' (x:xs) = qsort' lt ++ [x] ++ qsort' ge
    where lt = [y | y <- xs, y < x]
          ge = [y | y <- xs, y >= x]

Note: Quicksort, definitely Hoare’s version, is inherently imperative to begin with, in my opinion. In fact, most algorithms are stated in an imperative way and so naturally find their way more easily into C rather than to a language like Haskell (because imperative is the way the machine executes it). And most of the time, that imperative nature so much contributes to their efficiency. Since we have to break free from this imperative nature when representing them in a functional language, we might not be effectively doing the exact thing. The above Quicksort implementation, for instance, is indeed different from Hoare’s version, but not at a conceptual level. And personally, I find it okay as long as they are not inefficient by an order of magnitude (the classic argument here is that we switched from Assembly to C and Java, although nothing can beat the former’s efficiency really). Also to note here is that Haskell, in particular, makes use of lazy evaluation which probably makes up in part for the ‘inefficiency’. I guess.

Coming back, although quick sort is the much touted example for Haskell’s elegance, it is not a one-off case. In fact, look at the following sorting algorithms – try to figure what is what. It should be fairly easy to tell because the functions ‘explain’ what the algorithm is in its natural form.

sort2 :: (Ord a) => [a] -> [a]
sort2 [] = []
sort2 xs = min' ++ sort2 rest
    where min' = [z | z <- xs, z == minimum xs]
          rest = [z | z <- xs, z /= minimum xs]

sort3 :: (Ord a) => [a] -> [a]
sort3 [] = []
sort3 (x:xs) = (filter (<=x) sort3 xs)++[x]++(filter (>x) sort3 xs)

And the following, which probably can be written in an even better way (hey, I’ve just begun!)

sort4 :: (Ord a) => [a] -> [a]
sort4 []  = []
sort4 [x] = [x]
sort4 xs  = fun (sort4 (take l xs)) (sort4 (drop l xs))
    where fun xs [] = xs
          fun [] ys = ys
          fun xall@(x:xs) yall@(y:ys)
             | x <= y    = x  : merge xs yall
             | otherwise = y : merge xall ys
          l = length xs `div` 2 

sort5 :: (Ord a) => [a] -> [a]
sort5 [] = []
sort5 xs = sort5 (init l) ++ [last l]
where pass []  = []
      pass [x] = [x]
      pass (x:y:xs)
          | x <= y    = x: pass (y:xs)
          | otherwise = y: pass (x:xs)
      l = pass xs

Like they say, a function in an FP language describes what it ‘is’, not how it ‘does’ something. I wonder how effective it would be to have an Algorithms course taught in Haskell. I guess algorithms could be conveyed clearly, albeit a bit unconventionally. On the downside, it is probably difficult to judge (read analyze) an algorithm by looking at its implementation in Haskell. In fact, a Haskell implementation might not be the most efficient for an algorithm. And I also wonder about data structures. An FP language like Haskell, from the looks of it, is perhaps less about getting things done via data structures and more about getting them done via functions and recursions and list comprehensions and higher order functions, etc. Anyway, let me see how deep the rabbit hole goes.

Anyway, been learning Haskell, primarily to get a real feel of the functional programming (FP) paradigm. Oh, by the way, if you are, like I used to be, one of those who have always been hearing about functional programming but never really dived into it, then here is the first thing you should know: The ‘functional’ in FP refers to the functions as we once knew – as we studied in mathematics – the f(x)s and g(x)s. It has got nothing to do with the conventional ‘functions’ in programming. Yeah, it doesn’t look as revealing a statement until you’ve actually thought about it and wondered why a C program that is completely comprised of ‘functions’ is not ‘functional’. The last time I recall being through such an Aha! moment was on finding out that the ‘programming’ in dynamic programming has zilch to do with the ‘programming’ as we know it. And from then on it just makes sense.

(They keep tricking us with such things though, don’t they?)

Was just thinking it would have been convenient if there was a way to express the ‘tightness’ using another one of those characters from the Greek alphabet, instead of having to say that so and so bound is tight every time. None of the existing asymptotic notations I know of (O, o, Ω, ω, Θ) help achieve this.

Perhaps just as well, we probably have enough notations already…

Among other things, I found a particular remark interesting. In 1972, when Richard Karp, in his famous paper, showed that many naturally occurring problems for which we didn’t know of a polynomial time algorithm, are in fact NP-complete, he also listed a few other such problems that couldn’t be proven to be NP-complete. The latter included NONPRIMES, which is the following problem:

“Given a number, is it composite?”

Interestingly, he listed this problem instead of PRIMES itself, which is:

“Given a number, is it prime?”

What got me wondering was why he chose to list NONPRIMES instead of PRIMES itself. (Not that it makes much of a difference, but, surely, PRIMES is much more impressive and prettier?)

So why did he? And what’s the difference at all, aren’t they complements of each other?

To understand that, let’s reformulate the questions as follows:

NONPRIMES: Are there two numbers less than n whose product is n?

PRIMES: Is the product of every possible pair of numbers less than n not equal to n?

First, remember that the input size is not the value of n but the length of its encoding which would be the number of bits in n which is logn. (For more info on this, visit this wikipedia link on pseudo-polynomial algorithms).

So here’s the thing: According to the lecture, the reason PRIMES wasn’t listed is that, at that time, it wasn’t clear whether PRIMES is in NP at all. On the other hand, it was easy to show that NONPRIMES is in NP: Given a “yes” instance of the problem (which would be a pair of numbers whose product is n), one could easily verify that it is indeed right by just multiplying and checking. Multiplication will take O(log²n) time.

Interesting history, wouldn’t you say?

But let’s talk about the other question: What’s the difference really between the two problems? Aren’t they complements of each other?

Well, the answer to that gives us some insight into complexity classes. If a problem is in NP, then it’s complement need not be in NP. The problems which are complements of the problems in NP form the class co-NP. NP and co-NP are thought to be not equal.

But, aren’t they effectively the same questions? Can’t I just say “yes” for PRIMES if I get a “no” for NONPRIMES and vice versa?

Yes, you can! But that doesn’t necessarily mean that the running time of ‘verifying that a “yes” instance is indeed right’, is the same for both NONPRIMES and PRIMES – and therein lies the rub. For NONPRIMES, as we saw above, the verification can be done in polynomial time. But for PRIMES, if the question we consider is the above (“whether the product of every possible pair of numbers less than n is not equal to n“), then a “yes” instance itself would be the set of all pairs of numbers less than n. That’s ⁿC₂ pairs. To verify that that they all multiply to a different number will take O(n² log ²n) time which is exponential to the input size, the number of bits.

How about that!

Of course, PRIMES need not be formulated as “whether the product of every pair is less than n“. There could be a better way to formulate the problem so that the “yes” instance is small enough and its verification also takes polynomial time. In 1972 nobody knew of such a way. Indeed, a few years later, someone did and it was proven that PRIMES is in NP.

And in 2002, it was proven that PRIMES and therefore NONPRIMES are in fact in P.

Understanding what the classes really stand for is therefore fundamental. I kinda wonder now if this whole thing should be thought of as a limitation of the way the complexity classes are defined.

p.s: Another interesting fact is that for all problems in P, the complements are also in P. Also, if a problem and its complement are both in NP (which is equivalent to saying that the problem is in both NP and co-NP), then I think it is believed that the problem is likely not NP-complete.