|
Dieses Gerät hat auch andere Anweisungen:
Anleitung Zusammenfassung
interface, we recommend that you support the default interface as well, since that is the only way to ensure long-term
portability. See the User's Guide section on building containers for an explanation of how to support both the standard and the
alternate allocator interfaces.
A generic allocator must be able to allocate space for objects of arbitrary type, and it must be able to construct those objects on
that space. For this reason the allocator must be type aware; but it must be aware on any arbitrary number of different types,
since there is no way to predict the storage needs of any given container.
Consider an ordinary template. Although you may be able to instantiate on any fixed number of types, the resulting object is
aware of only those types and any other types that can be built up from them (T*, for instance), as well as any types you
specify up front. This won't work for an allocator, because you can't make any assumptions about the types a container will
need to construct. It may well need to construct Ts (or it may not), but it may also need to allocate node objects and other data
structures necessary to manage the contents of the container. Clearly there is no way to predict what an arbitrary container
might need to construct. As with everything else within the Standard Library, it is absolutely essential to be fully generic.
The Standard Allocator interface solves the problem with member templates. The precise type that you are going to construct
is not specified when you create an allocator but when you actually go to allocate space or construct an object on existing
space. This clever solution is well ahead of nearly all existing compiler implementations.
Rogue Wave's alternative allocator interface uses a different technique. The alternate interface breaks the allocator into two
pieces: an interface and an implementation. The implementation is a simple class providing raw un-typed storage. Anything
can be constructed on it. The interface is a template class containing a pointer to an implementation. The interface template
types the raw memory provided by the implementation based on the template parameter. Only the implementation object is
passed into a container. The container constructs interface objects as necessary, using the provided implementation) to manage
the storage of data.
Since all interface objects use the one copy of the implementation object to allocate space, that one implementation object
manages all storage aquisition for the container. The container makes calls to the allocator_interface objects in the same way
it would make calls to a standard allocator object.
For example, if your container needs to allocate T objects and node objects, you need to have two allocator_interface objects
in your container:
allocator_interface
node_allocator;
You then use the value_allocator for all allocation, construction, etc. of values (Ts), and use the node_allocator object to
allocate and deallocate nodes.
The only significant drawback is the inability to provide special pointer types and alter the behavior of the construct and
destroy functions provided by an allocator, since these must reside in the interface class. If your compiler provides partial
specialization then this restriction goes away, since you can provide specialized interface's along with your implementation.
Standard Interface
class allocator; {
typedef size_t size_type;
typedef ptrdiff_t difference_type;
template
{
typedef T* pointer;
typedef const T* const_pointer;
typedef T& reference;
typedef const T& const_reference;
typedef T value_type;
};
allocator ();
~allocator ();
template
address (typename types
template
address (typename types
...
PC Desktops - HP Integrity NonStop J-Series (850.45 kb)
PC Desktops - HP NonStop G-Series (850.45 kb)
PC Desktops - HP NonStop L-Series (850.45 kb)