Wednesday, May 22, 2013

Debug: undefined reference to 'vtable for XXXClass'

undefined reference to 'vtable for XXXClass'

If a class defines virtual methods outside that class, then g++ generates the vtable only in the object file that contains the outside-of-class definition of the virtual method that was declared first:
//test.h
struct str
{
   virtual void f();
   virtual void g();
};

//test1.cpp
#include "test.h"
void str::f(){}

//test2.cpp
#include "test.h"
void str::g(){}
The vtable will be in test1.o, but not in test2.o
This is an optimisation g++ implements to avoid having to compile in-class-defined virtual methods that would get pulled in by the vtable.
The link error you describe suggests that the definition of a virtual method (str::f in the example above) is missing in your project.

Wednesday, May 15, 2013

Problem solved: Why doesn't Chrome remember its window size settings?

Position of the window is only saved if the state (maximized/minimized/restored) is changed.
So, move the window to where you want it, then size it a little (this can be done before the move), and then shut down Chrome and restart. This is still really a bug, but at least there is an easy work around. 
Note: in fact, needn't to restart the Chrome.

Emacs on windows 7, setting up color themes


  1. Create this folderC:\Users\your_user_name\AppData\Roaming\.emacs.d\color-theme-6.6.0 (change or remove the version number as you like)
  2. Go to color-theme homepage and get the latest.  I got color-theme-6.6.0.zip
  3. Unzip and dump the file color-theme.el and the folder themes into the folder you created in step 1
  4. As per the references for ColorTheme and emacs Load Path, add the following to your.emacs (you may have to strip out any previous color theme settings yourself):
         (add-to-list 'load-path "~/.emacs.d/color-theme-6.6.0") 
         (require 'color-theme)
         (setq color-theme-is-global t)
         (color-theme-initialize)
         ;; A nice dark color theme
         (color-theme-lawrence)

Wednesday, May 8, 2013

Virtual destructors for base class


Always forget to do this....mark!

Virtual destructors are useful when you can delete an instance of a derived class through a pointer to base class:
class Base 
{
    // some virtual methods
};

class Derived : public Base
{
    ~Derived()
    {
        // Do some important cleanup
    }
}
Here, you'll notice that I didn't declare Base's destructor to be virtual. Now, let's have a look at the following snippet:
Base *b = new Derived();
// use b
delete b; // Here's the problem!
Since Base's destructor is not virtual and b is a Base* pointing to a Derived object, delete bhas undefined behaviour. In most implementations, the call to the destructor will be resolved like any non-virtual code, meaning that the destructor of the base class will be called but not the one of the derived class, resulting in resources leak.
To sum up, always make base classes' destructors virtual when they're meant to be manipulated polymorphically.
If you want to prevent the deletion of an instance through a base class pointer, you can make the base class destuctor protected and nonvirtual; by doing so, the compiler won't let you call delete on a base class pointer.
You can learn more about virtuality and virtual base class destructor in this article from Herb Sutter.

A virtual constructor is not possible but virtual destructor is possible. Let us experiment....
#include <iostream>
using namespace std;
class base
{

public:
    base(){cout<<"Base Constructor Called\n";}
    ~base(){cout<<"Base Destructor called\n";}

};
class derived1:public base
{

public:
    derived1(){cout<<"Derived constructor called\n";}
    ~derived1(){cout<<"Derived destructor called\n";}

};
int main()
{

    base* b;
    b=new derived1;
    delete b;

}
The above code output the following....
Base Constructor Called
Derived constructor called
Base Destructor called
The construction of derived object follow the construction rule but when we delete the "b" pointer(base pointer) we have found that only the base destructor is call.But this must not be happened. To do the appropriate thing we have to make the base destructor virtual. Now let see what happen in the following ...
#include <iostream>
using namespace std;
class base
{

public:
    base(){cout<<"Base Constructor Called\n";}
    virtual ~base(){cout<<"Base Destructor called\n";}

};
class derived1:public base
{

public:
    derived1(){cout<<"Derived constructor called\n";}
    ~derived1(){cout<<"Derived destructor called\n";}

};
int main()
{

    base* b;
    b=new derived1;
    delete b;

}
the output changed as following
Base Constructor Called
Derived constructor called
Derived destructor called
Base Destructor called
So the destruction of base pointer(which take an allocation on derived object!) follow the destruction rule i.e first the derived then the base. On the other hand for constructor there are nothing like virtual constructor. Thanks (Write Code and have fun!!!)