[4] The Symbian container Symbian did not embrace STL at the beginning of its design. This requires that it re-create some wheels, and the container is one of them. The designers of the carray series container Symbian like the complicated inheritance structure and Paul Vientiane class. The carray series container is the product of this concept. Carray is a sequential container, which is equivalent to the vector + List of STL and more. Carray series containers use the carrayxxxyxx naming method at the bottom of inheritance, that is, the classes that can be instantiated, that is, carray + Object Unit Storage + object segment storage. The Object Unit storage method represents how each unit data in a container is stored. There are four main methods in carray:
- Flat, each data in the container is of the same type;
- VaR, the length of each data in the container, can be different;
- Pak: the data in the container is divided into several parts. Each part has a leading-byte representing the length of the segment, such as the descriptor;
- PTR, the container stores pointer data of the cbase subclass object.
Each container has an important parameter. It is an integer called granularity, that is, the number of elements in each group. A group is the unit in which the carray container allocates memory. In the granularity category, all elements are stored in the preceding four modes. However, granularity is always a limited number, when the elements in the container are filled with granularity, a new space is required for storage. Each new space is a granularity unit. There are two connection modes between each group of units. One is a fix and the other is a Seg. There is a classic image in the Symbian OS explained. The storage modes of various arrays are clear and stolen, as shown above. From the storage point of view, the flat method is like an array. the PTR seems to be consistent with the VaR method, and the pointer exists together, pointing to objects in the heap, but in essence, the implementation of PTR is similar to the underlying flat, while VaR is converted to pointer customization. The storage of Pak is a little weird. Each batch of elements has a leading-byte number parameter, which is beyond your imagination. This is all about the descriptor. The fix between segments is like a vector. Every time you expand the storage capacity, you need to re-allocate the memory. It is suitable for fixed-length scenarios, rather than getting longer. And seg, similar to list, links between segments. If a Seg object of granularity is completely reduced to a linked list, there is no doubt that if you need to increase the storage capacity, the seg method array should be your favorite... At the interface level, carray supports data writing interfaces such as appendl, insertl, and delete, as well as data reading interfaces such as at and operator [], and also supports sort, find, compress and other data query and processing interfaces. The specific implementation is associated with the underlying storage. I have not read the relevant information and can only trust it unconditionally... The rarray family of rarray containers has two members: rarray and rpointerarray. It is easy to think of the Symbian naming style. The former stores common stack objects and the latter stores pointers. The implementation of the rarray series is much clearer and more pure than carray. They are actually the encapsulation of the C Array Based on X * or x *, which is close to the STL vector mode. However, compared with STL, its template behavior is a bit false. All Symbian books will say that when you need to approach an array like vector, use rarray instead of carrayfixflat. The reason is that there are many reasons. In essence, carray is slowed down by the overall thinking of Symbian. Its Inheritance structure is very deep, and each layer has to do some additional check work, reducing the efficiency, rarray is basically tailored for this, with no additional overhead. In terms of int, uint, and other basic data types, it has made great effort to make the template special, further improving the efficiency. Therefore, it is not uncommon for the industry to focus on carrayfixflat with high performance. Other containers in Symbian also have some containers, such as the cdescarray array. They are the same root as the carray series containers, but they have changed their faces and provide additional interfaces for descriptors, it can better perform string comparison and other operations. In Symbian, I have not found some non-linear containers, such as map, such as hash, such as tree. If so, it's just me. If not, it's actually me, because I can't figure out how Symbian makes such a decision. Thin templates forcibly inserts some advertisements about the Symbian template. As we all know, the C ++ template has two outstanding features:
- Efficient. The compilation period determines the type and ensures the running efficiency during the runtime.
- Security. The compilation period determines the type to ensure the security during the runtime.
However, in order to achieve this effect, the cost is also paid, that is, the type of expansion, compared with the runtime technology, the program volume has increased a lot. As a mobile phone operating system, Symbian adds a pattern to the template to try both the fish and the bear's paw. Specifically, it does not take advantage of template efficiency. It only uses the features of template security and runtime technology to reduce the size of the program. These templates are called thin templates. From the implementation perspective, the implementation of a standard template container may be:
Template <class T>
Class array <t>
{
Public:
T getdata (INT index );
PRIVATE:
T * data;
};
In this case, if there are ten different types of carray, then ten different classes will be compiled to expand the volume. The thin templates mode of Symbian is used as follows:
Template <class T>
Class array <t>: Private basearray
{
Public:
T getdata (INT index );
};
Class cbasearray
{
Protected:
Void * data;
};
On the surface, it is still a template class, but in fact, the storage is not converted to void * by type *. Using private inheritance to derive the storage of the base class, instead of the interface of the base class, re-construct the interface based on template parameters. In this way, the security is guaranteed, and many errors can be exposed during the compilation period. Because the underlying implementation does not use templates, it saves a part of the volume overhead. This implementation is similar to the earlier Java template, it only sacrifices the performance advantage. For the underlying layer, the advantage may be greater than the disadvantage, but for its own applications, it may not be necessary. Therefore, if you create a template by yourself and consider the application scenario, you do not need to stick to the so-called tiny templates...
======================================
The following is a real plug-in Advertisement * _ * On Symbian,Youdao shopping assistantAnd has been released. The features of the first version are not very rich yet, and some bugs are still being processed. You are welcome to download and use the s60 V3 kids shoes...
