When true != true

If we define a boolean variable, say:

bool xyz;

then when we have to do some kind of a comparison we may do this as follows:

if(xyz == true)

When I used to be a new programmer, I used to always do this as follows:

if(true == xyz)

I think the way I did it is more robust and less error prone because you can by mistake do as follows:

if(xyz = true) //Single = instead of ==

The problem with my approach is that the code readability is affected and most people hate to see code like this. Instead, I started doing what normal people would do but making sure that I always use '==' and not '='.

Now some of you may be thinking why not:

if(xyz)

True, in case of Boolean this is a simplest way to do it and I had personally no problem with it until recently. While reviewing some code, I noticed that an engineer had changed a piece of code from:

if(xyz == true) to if(xyz)

Initially I thought that it may be that he did not like the '==' as its redundant. So when I checked his other code, I realised that he may have done this for a reason. Executing his code in the debug mode worked fine. So I changed:

if(xyz) back to if(xyz == true) and lo and behold, the test started to fail.

Putting a breakpoint I can see that while on the statement:

if(xyz == true)

the debugger shows xyz is 'true' but the comparison fails.

As usual digging into the problem further, I found that in one of the constructors, xyz was not initialised and the default garbage value appeared to show it as 'true'.

So its again got me into thinking that it may be better to write if(xyz == true) instead of if(xyz) as it may help in catching uninitialised variables. The best thing of course would be to make sure all variables in the class, whether public, protected or private are initialised.

Opinions welcome!

Debugging Mutex and Locks

When there are multiple Mutex's in the program, it may be required to find if a particular thread is locked far longer than necessary. This can cause problems and the output may not be what is expected.

To get round this, I took an old example from here and modified it to help me print some debugging info.

I modified the printSomething() in Singleton.h to add a sleep as follows:

  void printSomething(char *name, int count)
 {
   Lock guard(mutex_);
   Sleep(10);
   Lock guard2(mutex_);
   std::cout << name << " loop " << count << std::endl;
 }

and I modified the Mutex.h as follows:

//Example from http://www.relisoft.com/Win32/active.html
#if !defined _MUTEX_H_
#define _MUTEX_H_

class Mutex
{
   friend class Lock;
public:
   Mutex () { InitializeCriticalSection (& _critSection); }
   ~Mutex () { DeleteCriticalSection (& _critSection); }
private:
   void Acquire ()
   {
     DWORD start = GetTickCount();
     EnterCriticalSection (& _critSection);
     DWORD elapsed = GetTickCount() - start;
     if (elapsed > 15)
     {
       //Debugging Info
        std::cout<<"Debugging Info: Waited at mutex for "<<elapsed<<std::endl;
     }
   }
   void Release ()
   {
       LeaveCriticalSection (& _critSection);
   }

   CRITICAL_SECTION _critSection;
};

#endif 

The output is as follows:

The small problem with the above approach is that if a Thread is deadlocked, we may not get the debug output as we would have to kill the process.

Consequences of Ignoring Compiler Warnings

Though this is a fictional program that I have picked up from here, I have seen similar problems in real life.

Lets say my program (below) was expected to return this

but instead returned:

Program as follows:

//Program tested on Microsoft Visual Studio 2008 - Zahid Ghadialy
#include<iostream>

using namespace std;

class Bclass
{
public:
 Bclass() {}
 virtual void func()
 {
   cout<<"In Bclass::func()"<<endl;
 }
};

class Dclass : public Bclass
{
public:
 Dclass() {}
 virtual void func()
 {
   cout<<"In Dclass::func()"<<endl;
   Bclass:func();
 }
};

int main()
{
 Dclass d;
 d.func();
 //...
  return 0;
}

The clue of the problem was given by the compiler that generated the following warning:

main.cpp(23) : warning C4102: 'Bclass' : unreferenced label

pointing to the line

Bclass:func();

The problem lies in the fact that due to a single : rather than :: the line above is being treated as label and since its an unreferenced label it goes back to the start of the same function.

You can read the complete discussion here. Make sure to check the warnings the next time your program behaves unexpectedly.