Recovery from implicit habits by using explicit keyword

This might be something ordinary for many.
But its only very recently that I have changed my coding style.
I find myself using the keyword explicit almost always now. Thus I would like to share why I started.

class Foo
{
public:
Foo(int x) {}
};


Its an innocent Foo class with a constructor that accepts an integer.

Constructors with single parameters servers us dual purpose:
1. just like all constructors it assists in construction of an object.
2. it behaves as an implicit conversion operator, that converts from type int to type Foo.

Consider this:

Foo f1(0); // line 1 - works
Foo f2 = 0L; // line 2 - works
Foo f3 = NULL; // line 3 - works

Line 1 is straight forward.
Line 2 is quite intuitively doing an implicit conversion from long to int.
Line 3 is plain WRONG. Its supposed to be a pointer type, but let say a typo occured. Surprisingly enough, it does compile.

Line 2 & 3 works because compiler internally turns off its static type checking (due to implicit conversion).

We would definitely want to avoid unintended usages like the "line 3" example.

This is something that we can achieve by the "explicit" keyword.

The only place explicit keyword can be used is in constructors.

For eg:

class Foo
{
public:
explicit Foo(int x) {}
};


Now if we have explicit, these are the new results:

Foo f1(0); // line 1 - works
Foo f2 = 0L; // line 2 - doens't work
Foo f3 = NULL; // line 3 - doesn't work


and in order make those lines work we will have to be more explicit during construction.

Foo f1(0); // line 1 - works
Foo f2 = static_cast<Foo> (0L); // line 2 - works
Foo *f3 = NULL; // line 3 - works


Explicit keyword helps us not to do silly mistakes which can turn be quite lethal if not paid attention to.

IMHO, its wise to always use the explicit keyword in your constructors with single parameter.
It also makes sense to use explicit keyword with constructors that have more than x parameters but (x-1) parameters have default values.

new never returns NULL

Recently I gave the Brainbench c++ test and came across an interesting question.

It was something like:

{
int *i = new int[10];
if(!i)
{
NoMemoryHandler();
}
}


In this question, the right answer is "NoMemoryHandler() is never called".

Thats because, in c++ new operator never returns a NULL. In case of failure new simply throws an exception std::bad_alloc.

Now if you catch the exception and handle the situation, then its fine. Otherwise, if you don't catch the exception, your lovely program will get terminated. (Thats so uncool!)

Now everytime whenever you gotta write code, it should be like:

{
try
{
int *i = new int[10];
}
catch(bad_alloc &e)
{
cout << "OK, new failed!! But on the positive side, I am aware of it !!" << endl;
}
}

Fortunately to our rescue there is another version of new which doesn't throw anything on failing.

With reference to GCC's online docs we come to know about the nothrow version of new.

{
int *i = new (nothrow) int[10];
if(!i)
{
cout << "new failed!! but now I am not a slave of exceptions !!" << endl;
}
}

When I use the standard version of new, I have to handle the exception it throws on failure, else my program gets terminated.
If I use the "nothrow" version of new, I still need to write some healing code, but then I am free of unnecessary try{} and catch(){} blocks.

Until and unless I have to customize "new" for specific needs, I would always prefer the "nothrow" verison.

-----------------------------------------------------------------------
And yeah... I got a 4.69 score. Transcript id: 7416277.

Thread Pool implementation using c++

I was browsing through some Design Patterns over the internet, and I recently came across the Thread Pool pattern. My natural reaction was to google around for some implementations.

I liked Blake Thompson's win32 implementation on Intel's website. Inspired from it, I thought of writing an implementation for unix/linux platform.

ThreadPool class manages all the ThreadPool related activities. This includes keeping track of idle threads and synchronizations between all threads.

ThreadPool class uses a WorkerThread class.

Now this WorkerThread is having a virtual function executeThis().
The user needs to subclass WorkerThread and implement executeThis() to assign the tasks.

You can download the code and documentation from http://code.google.com/p/cppthreadpool/
This code is licensed under GPL v3. So feel free to use it, modify it, and whatever it.

I have currently tested it under cygwin environment, but I am expecting it to work in unix and linux environments as well (since it uses POSIX threads). It will be great if someone with unix/linux environment can test it.

If you have any doubts about how to use this Thread Pool implementation, then please feel free to ask me at shobhitgupta12@gmail.com