Symbian Notes "One"--symbian naming act

Each of the beauty of the remaining C + + coder, the first time to see the Symbian C + + program, the first response is: This ghost code how to indent? Next, everyone will have a question: what do you mean by a messy prefix on functions and classes?

Baby again ugly is parents born, the formation of this appearance although very helpless, but it is also a reason. In my view, the core point of the Symbian nomenclature is to better manage memory resources. C + + human flesh memory management mode, in giving people to control the pleasure of byte, but also bring trouble to each line of code troubles. Nomenclature is one of the ways Symbian designers can use to help manage memory resources.

Class naming

Symbian's class, usually with a letter prefix, such as C, M, T, R, H, and so on.

All subclasses derived from CBase begin with C and are shaped like cxxxx. Each of the correctly designed, non-abstract (not-instantiated) C classes can only be allocated on the heap. To ensure this, each of the instantiated C classes should be based on Symbian's two-phase construction pattern. But of course, this can be an accident. For example, some control object classes derived from Ccoecontrol need to construct the member objects of the class from the resource file (not just the constructl in the two phase), which makes it possible to encapsulate it in a two-stage construct.

Have done. NET or Java people should be aware of the benefits of maintaining a single root type system. NET in the days without generics, it is through this common root to implement some basic containers and methods. But this benefit is not evident in C + +, especially Symbian C + +. Because C + + has a void * (a gorgeous turn in Symbian to Tany *), there are templates that can be used to do something similar. More importantly, in Symbian C + +, in order to save space, the virtual table to reduce the RTTI, so that the Symbian C + + class lost the ability to dynamic_cast, which led to the entire Symbian in the Run-time dynamic identification, is very weak.

So, one of the most important reasons for deriving objects from the CBase class is for memory management. CBase did a very important thing by setting up copy constructors and assignment functions as private. This means that all subclasses derived from CBase are castrated by default and lose the ability to copy constructs. This is to remind all users that a shallow copy of the C object is not welcome, if you want to provide the copy function of the object (to be deep copy, do not shallow ...) ), often using some clonel and other interfaces to achieve, to ensure the unity of behavior.

C's class, are flocking to the heap, the stack of live, left to the T class to complete. The T class has no particular inheritance structure, and each T class needs to be randomly allocated on the heap or stack. Most of the time, they should be on the stack, allocated on the stack, and can quickly copy, once the destructor, so the resources are released, life does not bring death without leaving a little residue. Therefore, they should not contain large chunks of data objects, but they can have very complex interfaces to increase the ease of operation. For example, Trgb, Trect and so on system class, is the typical person imp big representative person. But T class is not C + + 's old plain class, it can have inheritance structure, such as Symbian in the description of the heap of the T class, there is a complex inheritance structure.

But the world is cruel, some classes, it is wrong to cast a fetus, make people not people, ghosts not ghosts. Hbuf, is the representative of this. In order to maintain formation and maintain the interface, HBUF derives from Tdesc to represent the Symbian descriptor assigned to the heap (the string ...). ）。 But unlike the general T class, because it occupies a dynamic change in space, it must be allocated on the heap, so that it loses the right to call T; On the other hand, for the interface, it derives the T class, in the exclusion of Dogan C + +, it can not derive from the CBase (inherited limitations, visible), was broken called C of the posterior. So, he took the special hat of H, said that it is allocated on the heap, but not drifting under the eaves of C class.

The R class, replaced by the popular description, is the handle class. It is born to manage resources, the R class itself is simple, usually distributed on the stack, can be copied, at this point very close to the T class. However, unlike the T class, the R class often has pointers to a heap object, points to resources such as files, or a large heap of data objects. When it is destructor, the default is not to deconstruct this pointed object, but to provide some interfaces similar to close,release, which require human flesh to be released manually. Some T classes also point to another heap or stack area, such as the Tptr class. One of the essential differences between the two is that the T class points to an object that is not allocated by itself, it simply provides a shortcut, regardless of whether the object is dead or dead, and the resource that the R class points to is often itself or another homogeneous assigned resource, and the resources that the R class object points to must be constructed from the object of this r class. The object destructor from this R class (two objects can be different, but the class is consistent).

In Symbian C + +, there are some classes that do not involve any memory resources. One is the interface class, which starts with M, which is equivalent to. NET interface, is a pure virtual class. Each of the classes in Symbian can be derived from several m classes, but can only be allocated from an object that has a memory resource. Theoretically, as a pure virtual class, it should provide a virtual destructor, but in Symbian C + +, this is often unwanted. Because in a world without Rtti, only the first inherited interface is likely to successfully deconstruct all objects. such as a class, the shape like class a:public cxxx, public mxxx. Only using the Cxxx interface to manage resources, delete the Mxxx interface, there is absolutely no way to release all the resources (unless there is no data in the cxxx ...). ）。 Symbian's heap objects tend to derive from CBase, so it is not possible to deconstruct objects from an M class, and this destructor is not a virtual matter.

Another class that does not contain any resources is the static class, which has no prefix in Symbian C + + and is the only one who doesn't wear a hat. This and. NET static class, contains only a bunch of statics, need to block all construction, destructor, copy interface (without this free, do not shield also indifferent ...) ）。 Although C + + has functions, but out of the enthusiasm for object-oriented, the use of such a static class, it is worth encouraging ...

function naming

In Symbian, the class is a hat, and the function is to wear trousers. In Symbian's functions (including member and non-member functions), there are often two suffixes, one is L and the other is LC. L, is to tell you that this function may be leave, for human-known language description, that is, this function throws an exception that needs to be handled with care. L is transitive, and if you ignore this l at the place where the function is invoked, then you need to add an L after this call function.

In addition to L, there is a further LC. This is usually a constructive function that tells you that it is not only possible to leave in the process of constructing it, but also that the assigned object is in the cleanup stack. This is a function that is close to the syntactic sugar, and if you need to invoke the associated interface of the constructed object in the subsequent part of this function, you should use the LC and then your own pop instead of L.

Other naming Act

There are also some objects that will be prefixed with. For example, the object's member variables are prefixed with the prefix i; function arguments, all with a (if the following is the beginning of the reason letter, you need to use an,*_*). In the member variable prefix, this is the commonly used means that can be distinguished from the member variable, helping to save the name of a variable in the brain cells. But on the function of the prefix, is a very strange thing, dissection has the art of the lily.

In Symbian, all the constants should be K-first, including the defined const amount, the _lit definition of the word constants, and so on. The enumeration type, which belongs to the T type, starts with T, and the enumeration value begins with E. Creating nomenclature for these types of things is a common tactic, but Symbian does not take the usual route, and the naming method does not bother to agree with others ...

Conclusion

In short, Symbian has developed a complex set of nomenclature rules that are expected to standardize memory management operations. But the cruelty of the world is that a standard without coercion is unreliable. Nomenclature is a weak constraint of things, the duration of the rush, it is impossible to ignore the compilation and run-time errors, but can unconditionally ignore the naming rules. Also, the nomenclature has a strong window-breaking effect, and once a function is not properly added L, all functions that call it directly and indirectly may use it incorrectly, thus burying the hidden danger. In addition, Symbian's nomenclature is also a flourish, it is easy to see the clue, unknowingly used the wrong, a team of everyone in the above make some mistakes, to the final naming act completely lost the effectiveness. However, even if the environment is bad, for individuals, or should be disciplined, no matter what, do not easily discard the right to name, so that may benefit everyone.