ObjectPointer instances represent safe portable references to managed objects, throw exceptions if incorrectly used and are able to catch such common errors as dereferencing invalidated or NULL_ID pointers, bad casts (if type information is available), etc. ObjectPointer instances hold this kind of static and dynamic information:
Static information (statically encoded into the pointer instance or set up at the moment of pointer creation and can not be changed since then):
Identification of the interface of the object being refered, cast object responsible for accessing the interface (for more information about the cast object, see Section 5.3.2, “Using Cast Object”).
Dereference semantics (local/remote).
Pointer interpretation utilized by the Garbage Collector (see the Massiv Core Programmer's Documentation for more detailed information).
Pointer replication flags, used to define migration/replication groups of objects.
Dynamic information
ObjectId of the referenced object, including its type information if available.
![[Note]](images/note.png) | Note |
|---|---|
ObjectPointers can point to "stand-alone" (addressable) objects only. For example one can not create ObjectPointer that accesses fourth element of an array embedded into an Object. In this way ObjectPointers are similar to Java or CORBA references. | |
![[Warning]](images/warning.png) | Warning |
|---|---|
Objects instantiated on the stack are not addressable. | |
Object pointer instances can be characterized by three main properties:
Is it a stack pointer or a pointer property?
Stack pointers are ObjectPointers that can be instantiated on the stack only and that are not properties. They are always used as temporary pointers only.
Pointer properties are real properties and thus can be stored in managed objects and containers. They can also be instantiated on the stack. The discrimination between stack pointers and pointer properties is purely because of implementation efficiency. Stack pointers are "stripped" versions of pointer properties, nearly as effecient as the native C++ pointers.
Is that pointer strong or weak?
This object pointer characteristics is related to pointer interpretation by the Garbage Collector and whether the object can point to remote objects.
Weak pointers can reference remote objects and do not keep referenced objects alive (GC ignores weak pointers while scanning for unreachable objects).
Strong pointers always reference local objects and are processed by the Garbage Collector while scanning for unreachable objects. The local characteristics is important as Core ensures that it is not violated when an object migrates. It is said that strong pointers implicitly define migration groups of objects (see Section 6.4, “Migration Groups”).
What is the dereference semantics? Local or remote?
What happens when an object pointer is dereferenced? Two semantics have been implemented: local and remote. Local semantics allows to access local objects only, both its methods and properties. Remote semantics gains access to methods of local or remote objects, every call is translated to a RPC call. Object's properties can not be accessed via remote pointers.