[1] C ++ coder in every aesthetic sense in the Symbian naming method. The first time I saw Program The first reaction is: this ghost Code How do I indent it? Next, everyone will have a question: what is the meaning of the messy prefix Suffixes in functions and classes? Even though the appearance is helpless, it is also a cause. In my opinion, the core starting point of the Symbian naming method is to better manage memory resources. The memory management mode of C ++ brings the troubles of every line of code while giving control to byte. The naming method is one of the ways Symbian designers can help manage memory resources. A class named Symbian class usually carries a letter prefix, such as C, M, T, R, and H. All child classes derived from cbase start with C, and are like cxxxx. Each correctly designed, non-Abstract (non-instantiated) Class C can only be allocated on the stack. To ensure this, every class C that can be instantiated should follow the two-phase construction mode of Symbian. But of course, this can be unexpected. For example, some control object classes derived from ccoecontrol will need to construct the Member objects of the class from the resource file (instead of being constructed through the conctl structl method in Stage 2 ), this makes it not suitable for encapsulation based on a two-stage structure. Done. net or Java users should understand what is the benefit of maintaining a single root type system ,. net in the days when there is no generics, it is through this root to implement some basic containers and methods. However, this benefit is not obvious in C ++, especially in Symbian C ++. Because c ++ has void * (turned to Tany * in Symbian in a gorgeous way) and templates, you can do something similar. More importantly, in Symbian C ++, in order to save space, the rtti item of the virtual table is reduced, and the class of Symbian C ++ loses the ability of dynamic_cast, as a result, the dynamic recognition capability of the entire Symbian during runtime is very weak. Therefore, it is important to derive objects from the cbase class for memory management. Cbase makes the copy constructor and the value assignment function private. This means that all subclasses derived from cbase are castrated by default, and the copy construction capability is lost. This is to remind all users that the shallow copy of the C object is not welcome. If you want to provide the copy function of this object (to make a deep copy, do not copy it ...), it is often implemented using some clonel and Other interfaces to ensure the uniformity of behavior. C classes are all routed to the heap, and the live on the stack is left to the T class for completion. Class T has no special inheritance structure. Each class t needs to be freely allocated on the stack or stack. Most of the time, they are waiting for stacks, which are allocated on the stacks and can be copied quickly. Once they are destructed, resources are released, life does not lead to death, but does not leave any residue. Therefore, they should not contain large data objects, but can have very complex interfaces to increase the convenience of operations. For example, trgb, trect, and other system classes are typical representatives of big people. However, t class is not the old plain class of C ++. It can have an inheritance structure. For example, the heap t class of descriptors in Symbian has a complex inheritance structure. However, the world is cruel. In some categories, it is wrong to give birth, so that no one is human, no ghost. Hbuf, which is represented in this section. To maintain the formation and interface, hbuf derives from tdesc to indicate the Symbian Descriptor (that is, the string...) allocated to the stack ...). But unlike the general t class, because the occupied space changes dynamically, it must be allocated on the stack, so it loses the right to call T. On the other hand, for the interface, it derives the t class, in C ++, which rejects multiple roots, it cannot be derived from cbase (the limitations of inheritance can be seen). It is broken down the path called C. As a result, H's special hat is carried, indicating that it is allocated on the stack, but not under the eaves of class C. The r class is replaced by the general description, that is, the handle class. It is born to survive in order to manage resources. The R class itself is very simple. It is usually allocated on the stack and can be copied, which is very similar to the T class. However, unlike class t, the R class usually has a pointer to a heap object, pointing to resources such as files, or a large volume of heap data objects. By default, it does not parse the objects pointed to, but provides some interfaces similar to close and release, which must be manually released. Some t classes also point to another heap or stack area, such as the tptr class. The essential difference between the two is that t class points to the object, instead of its own allocation, it only provides a shortcut, not to point to the life and death of the object; and R class points to the resource, it is often the Resource Allocated by itself or another similar type. The resource pointed to by the R class object must be constructed from the R class object, analyze the structure of the r Class Object (the 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 and is a pure virtual class. Classes in each Symbian can be derived from several M classes, but can only be allocated from an object with memory resources. Theoretically, as a pure virtual class, a virtual destructor should be provided. However, in Symbian C ++, this is usually not required. In a world without rtti, only the first inherited interface can successfully parse all objects. For example, a class, such as class A: Public CXXX, public mxxx. Only the CXXX interface can be used to manage resources and delete the mxxx interface. There is no way to release all resources (unless there is no data in CXXX ...). The heap objects of Symbian are often derived from cbase. Therefore, it is impossible to describe objects from an M class. This destructor cannot be virtual, And it is irrelevant. Another class that does not include any resources is a static class. In Symbian C ++, they do not have any prefixes and are the only one who does not wear any hats. This and.. net static class, which only contains a bunch of static methods. It is necessary to shield all the constructors, destructor, and copy interfaces (it doesn't matter if you don't have the time to block them ...). Although C ++ has functions, it is very encouraging to use such static classes out of enthusiasm for Object-Oriented... The function is named in Symbian, the class is wearing a hat, and the function is wearing pants. In Symbian functions (including Member and non--member functions), there are usually two suffixes: L and LC. L is to tell you that this function may be leave. In other words, this function throws an exception and requires careful processing. L is passed. If you do not care about this l when calling this function, then you need to add an L after calling the function. In addition to L, there are further LC. This is usually a constructive function. It tells you that during the construction process, not only may leave, but also the allocated objects are in the cleaning stack. This is a function similar to syntactic sugar. If you need to call the interface of the constructed object in the subsequent part of this function, you should use LC and pop it by yourself instead of L. Other naming methods also contain some objects with a prefix. For example, all member variables of an object carry the prefix I, and all function parameters carry a (if it is followed by a reason letter, An, * _ * is required ,*_*). Adding a prefix to a member variable is a common method that can be separated from a member variable to help save the brain cells that name a variable. However, adding a prefix to the function form is a very strange thing, with an artistic effect. In Symbian, all constants should start with K, including the defined const volume and the character constant defined by _ struct. The enumeration type, which belongs to the same type as t, starts with t, and the enumerated value in it starts with E. Creating naming rules for these types of things is a common method, But Symbian is not unusual. The naming method is different from others... Conclusion In short, Symbian has developed a complex set of naming rules, which are expected to standardize memory management and other operations. However, the cruelty of the world is that there is no mandatory standard and it is unreliable. The naming method is a weak constraint. It is impossible to ignore compilation and runtime errors when the construction period is too short. However, naming rules can be ignored unconditionally. In addition, the life name method has a strong window-breaking effect. Once a function is not properly added to L, all functions that call it directly or indirectly may use it incorrectly, thus laying hidden risks. Moreover, the Symbian naming method is also very sophisticated. It is easy for people to see clearly what is going on. Without knowing it, they make mistakes. Each team makes some mistakes on this, by the end, the naming method completely loses its efficiency. However, even if the environment is poor, individuals should be strict with themselves. In any case, do not discard the correct names so that they can benefit everyone...
