A collection is a container that collects together descendents of the PObject class.
![]() | Construction |
![]() | Overrides from class PObject |
![]() | Common functions for collections |
![]() | PCollection ( int dummy, const PCollection * coll ) Constructor used in support of the Clone() function. |
Common functions for containers
Run Time Type functions
Comparison functions
I/O functions
Miscellaneous functions
A collection is a container that collects together descendents of the PObject class. The objects contained in the collection are always pointers to objects, not the objects themselves. The life of an object in the collection should be carefully considered. Typically, it is allocated by the user of the collection when it is added. The collection then automatically deletes it when it is removed or the collection is destroyed, ie when the container class has no more references to the collection. Other models may be accommodated but it is up to the programmer to determine the scope and life of the objects.The exact form of the collection depends on the descendent of PCollection and determines the access modes for the objects in it. Thus a collection can be an array which allows fast random access at the expense of slow insertion and deletion. Or the collection may be a list which has fast insertion and deletion but very slow random access.
The basic paradigm of all collections is the "virtual array". Regardless of the internal implementation of the collection; array, list, sorted list etc, the user may access elements via an ordinal index. The implementation then optimises the access as best it can. For instance, in a list ordinal zero will go directly to the head of the list. Stepping along sequential indexes then will return the next element of the list, remembering the new position at each step, thus allowing sequential access with little overhead as is expected for lists. If a random location is specified, then the list implementation must sequentially search for that ordinal from either the last location or an end of the list, incurring an overhead.
All collection classes implement a base set of functions, though they may be meaningless or degenerative in some collection types eg Insert() for PSortedList will degenerate to be the same as Append().
The exact semantics depends on the specific type of the collection. So the function may not place the object at the "end" of the collection at all. For example, in a PSortedList the object is placed in the correct ordinal position in the list.
The exact semantics depends on the specific type of the collection. So
the function may not place the object before the specified object at
all. For example, in a PSortedList the object is placed in the
correct ordinal position in the list. Note that the object values are compared for the search of the
before parameter, not the pointers. So the objects in the
collection must correctly implement the PObject::Compare()
function.
The exact semantics depends on the specific type of the collection. So
the function may not place the object at the specified index at all.
For example, in a PSortedList the object is placed in the correct
ordinal position in the list.
Note that the comparison for searching for the object in collection is
made by pointer, not by value. Thus the parameter must point to the
same instance of the object that is in the collection.
Note if the index is beyond the size of the collection then the
function will assert.
The objects are removed from the last, at index
(GetSize()-1) toward the first at index zero.
The exact semantics depends on the specific type of the collection. For
some, eg PSortedList, the object inserted will not stay at the
ordinal position. Also the exact behaviour when the index is greater
than the size of the collection depends on the collection type, eg in
an array collection the array is expanded to accommodate the new index,
whereas in a list it will return FALSE.
For example:
virtual PINDEX Insert( const PObject & before, PObject * obj )
obj - New object to place into the collection.virtual PINDEX InsertAt( PINDEX index, PObject * obj )
obj - New object to place into the collection.virtual BOOL Remove( const PObject * obj )
virtual PObject* RemoveAt( PINDEX index )
virtual void RemoveAll()
virtual BOOL SetAt( PINDEX index, PObject * val )
val - New value to place into the collection.virtual PObject* GetAt( PINDEX index ) const
virtual PINDEX GetObjectsIndex( const PObject * obj ) const
virtual PINDEX GetValuesIndex( const PObject & obj ) const
PINLINE void AllowDeleteObjects( BOOL yes = TRUE )
coll.SetAt(2, new PString("one"));
coll.SetAt(2, new PString("Two"));
would automatically delete the string containing öne" on the second
call to SetAt().
void DisallowDeleteObjects()
The dummy parameter is there to prevent the contructor from being invoked automatically by the compiler when a pointer is used by accident when a normal instance or reference was expected. The container would be silently cloned and the copy used instead of the container expected leading to unpredictable results.
Alphabetic index HTML hierarchy of classes or Java