* Singleton -- the most commonly used pattern.
There are some singleton classes in IIIMSF such as IMLog, IMSignal
etc, and basicly follows the scheme below:
class Singleton
{
    static Singleton * _pInstance;
    Singleton ();
    vitual ~Singleton ();
public:
    static Singleton * get_instance ();
    static Singleton * construct ();
    static void * cleanup ();
};
It's not correct! At least, we should declare the copy constructor as
private like that:
private:
    Singleton (const Singleton& other);
* State pattern applied in IIIM
First, let's to see how the classic state pattern looks like.
+------------+              +-----------+
|   Context  |<>------------|   State   |
+------------+              +-----------+
| Request () |              | Handle () |
+------------+              +-----------+
                                  A
                                  |
                    +-------------+----- ... ...
                    |             |
              +-----------+    +-----------+
              |  StateA   |    |  StateB   |
              +-----------+    +-----------+  (concrete states)
              | Handle () |    | Handle () |
              +-----------+    +-----------+
The member functions of concrete states, take the reference of
"Context" as one argument. Concrete states use this reference to call
it's change_state () function. Every concrete state knows what will be
the next state after a certain operation. And state object is usually
a singleton.
In IIIM, ICState is the "Context", IIIMP_ICState is the parent "State"
class, while IIIMP_ICState_REQUESTED, and IIIMP_ICState_WAITING
classes are the concrete state classes. In case of IMState, it's the
same.