There are two kinds of objects:

Objects created and destroyed by the application only: Local Devices, Inputs, Outputs...
Objects whose lifetime is neither persistent nor predictable: Messages, Destinations...

An application developer does not have to worry about the first category of objects. A pointer to such an object remains valid until the application explicitly discards the object using a dedicated method.

Beware that the second kind of objects might be internally discarded while still referred to by the application. A "hook" mechanism has been implemented to prevent the application from using bad pointers. The objects, named Hooked Objects, have methods allowing the application to Acquire or Release the object. A Hooked Object cannot be destroyed while it is hooked. Nevertheless, the application developer must take care to release the object as many times as it's been acquired, otherwise the object will remain in memory, inducing a memory leak that will quickly prove fatal in embedded systems.

Internally, a Trash Can is used to handle all Hooked Objects. A monitoring is performed by the Cerbere, a piece of code part of the CHAI, which broadcasts a Warning Message if something abnormal occurs (e.g. a continuously increasing Trash Can due to a missing Release).

In conclusion:

Standard objects whose lifetime is under CHAI control inherit from CPNS::IObject interface.
Hooked objects, allowing application side lifetime control, inherit from CPNS::IHookedObject.

In any case, it is always possible to get notified when an object is about to be destroyed using its CPNS::IObject_NotificationHandler.

See Also: The CPNS::IObject inheritance diagram