Explains when to use dynamic buffers and whether to select flat or segmented type of buffer.
Dynamic buffers present two choices to potential users:
Use a more conventional scheme, such as a descriptor if:
the exact size of your data is known at compile time, or in any case before the data begins to be read into memory
the exact size is not known, but its maximum limit is known, and that limit is sufficiently small that it involves little waste
the functions you require are provided by the descriptor classes
On the other hand, use dynamic buffers if:
the exact size of your data is not known and it’s possible that the data may grow significantly during its lifetime
the class you are working with requires the use of buffers — for example, the array classes derived from CArrayFixBase, CArrayVarBase and CArrayPakBase use buffers in their implementation.
The dynamic buffer classes are a general solution for requirements such as these. In some quite specialised cases, the particular requirements of the problem are more exacting than those met by dynamic buffers, and a specialised buffer scheme may be necessary.
If dynamic buffers are appropriate, use flat buffers if:
efficiency in transforming between buffer position and memory address is very important
the re-allocations needed to extend the buffer are sufficiently rare that they do not cause intolerable amounts of data copying or heap fragmentation
there is an upper bound on the size limit, and can reserve sufficient room, using SetReserveL() before inserting (this is typically followed by call to InsertL()).
On the other hand, use segmented buffers:
to minimise the heap thrashing and copying that can be associated with re-allocating a single flat buffer
if there is a concern about the performance of frequent insertions and deletions, which even without much heap allocation, can be better with segmented buffers as not all data after the insertion/deletion point needs to be shuffled to complete the operation.
Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies).
All rights
reserved. Unless otherwise stated, these materials are provided under the terms of the Eclipse Public License
v1.0.