Saturday, October 11, 2008

When should your destructor be virtual?

When should your C++ object's destructor be virtual?
First of all, what does it mean to have a virtual destructor?
Well, what does it mean to have a virtual method?
If a method is virtual, then calling the method on an object always invokes the method as implemented by the most heavily derived class. If the method is not virtual, then the implementation corresponding to the compile-time type of the object pointer.
For example, consider this: class Sample {
public:
void f();
virtual void vf();
};
class Derived : public Sample {
public:
void f();
void vf();
}
void function()
{
Derived d;
Sample* p = &d;
p->f();
p->vf();
}
The call to p->f() will result in a call to Sample::f because p is a pointer to a Sample. The actual object is of type Derived, but the pointer is merely a pointer to a Sample. The pointer type is used because f is not virtual.
On the other hand, the call to The call to p->vf() will result in a call to Derived::vf, the most heavily derived type, because vf is virtual.
Okay, you knew that.
Virtual destructors work exactly the same way. It's just that you rarely invoke the destructor explicitly. Rather, it's invoked when an automatic object goes out of scope or when you delete the object. void function()
{
Sample* p = new Derived;
delete p;
}
Since Sample does not have a virtual destructor, the delete p invokes the destructor of the class of the pointer (Sample::~Sample()), rather than the destructor of the most derived type (Derived::~Derived()). And as you can see, this is the wrong thing to do in the above scenario.
Armed with this information, you can now answer the question.
A class must have a virtual destructor if it meets both of the following criteria:
You do a delete p.
It is possible that p actually points to a derived class.
Some people say that you need a virtual destructor if and only if you have a virtual method. This is wrong in both directions.
Example of a case where a class has no virtual methods but still needs a virtual destructor: class Sample { };
class Derived : public Sample
{
CComPtr m_p;
public:
Derived() { CreateStreamOnHGlobal(NULL, TRUE, &m_p); }
};
Sample *p = new Derived;
delete p;
The delete p will invoke Sample::~Sample instead of Derived::~Derived, resulting in a leak of the stream m_p.
And here's an example of a case where a class has virtual methods but does not require a virtual destructor. class Sample { public: virtual void vf(); }
class Derived : public Sample { public: virtual void vf(); }
Derived *p = new Derived;
delete p;
Since the object deletion occurs from the pointer type that matches the type of the actual object, the correct destructor will be invoked. This pattern happens often in COM objects, which expose several virtual methods corresponding to its interfaces, but where the object itself is destroyed by its own implementation and not from a base calss pointer. (Notice that no COM interfaces contain virtual destructors.)
The problem with knowing when to make your destructor virtual or not is that you have to know how people will be using your class. If C++ had a "sealed" keyword, then the rule would be simpler: If you do a "delete p" where p is a pointer to an unsealed class, then that class needs have a virtual destructor. (The imaginary "sealed" keyword makes it explicit when a class can act as the base class for another class.)

Wednesday, September 3, 2008

LaTeX for Blogger

http://wolverinex02.googlepages.com/emoticonsforblogger2

How to setup an Openafs client on Ubuntu

Back to lug

Copy krb5.conf to /etc/krb5.conf

sudo apt-get install krb5-user openafs-krb5

  • change default realm to ACM.UIUC.EDU (case matters)
  • Kerberos servers are kerberos.acm.uiuc.edu and kerberos-1.acm.uiuc.edu
  • admin server is kerberos.acm.uiuc.edu

sudo apt-get install gcc-3.4 build-essential openafs-client

  • AFS Cell = acm.uiuc.edu (case matters)
  • default cache size is fine b/c you aren't going to use it.

sudo apt-get install module-assistant
sudo m-a prepare openafs-modules
sudo module-assistant auto-build openafs-modules
sudo dpkg -i /usr/src/openafs-modules-*.deb

cd /etc/openafs
sudo vim afs.conf

  • add: FNORD="-memcache -stat 10000 -blocks 65536 -chunksize 19"
    This sets a 64MB in-memory cache. If you want to use a disk cache you'll need to make sure that /var/cache/openafs is ext2 and its probably a good idea to dedicate a parition to it.
  • set: OPTIONS=$FNORD

sudo vim afs.conf.client

  • change AFS_DYNROOT=false to true

If you're running Ubuntu Dapper, there is an issue I've come across with the module not being auto-inserted upon reboot. This can be fixed by running a simple:

sudo depmod -a

sudo shutdown -r now "installing openafs"

Everything should be working!


your attribute: /afs/nd.edu/user39/jgai