Type - Core Concept ofOop and GP

Type - Core Concept of Programming Language Purple Yunying

Keywords: Type, Concept, Model, Refinement, Constraint, Constrained Genericity, Interface, Boost Concept Check, OOP, GP, C

The author of "Object Unencapsulated: Eiffel, Java and C " said that Object-Oriented should be named type-oriented [1] [5]; Mr. Houjie said in the article, STL is actually in pan Under the type of thinking, a systematic, symbolic classification is established. Oh, what is classified? Or type. [3] It seems that the concept of "type" is worth talking about it.

In object-oriented design (OOD), "classification" is an important step, and a well-designed class hierarchy is an important result of OOD. The levels and interfaces of the class are well defined, the implementation of the benefit software system, the maintenance and future extension: they will surprise, many intricate relationships do not speak clearly in the clear type level; and the failure class hierarchical structure It is a source of disasters: In order to bypass the binding of unreasonable types, the codec has to use all kinds of skills to use [4] - including the mandatory type CAST, directly to the object memory Wait, and these techniques tend to follow potentially bug shadows.

In the summary and development of the data structure, the type also plays an important role. The introduction of ADT is a milestone. In the early language, Struct (C), Record (Pascal) and other composite structural types are supported by ADT. What is ADT? Abstract data type.

In programming languages, the concept of type has been continuously developed. The language is better efficient to support the language maturity of the language. OOP language The type of support mechanism includes Class, Interface, Inheritance, Polymorphism, RTTI, various CAST, etc., which makes a lot of convenience for programming, because all concepts have counterparts in language. For the image interpretation of the type in the OOP language, please refer to the "Selection and Learning of Wrist Program Design Language" (published in October 2001) and "Object Unencapsulated: Eiffel, Java and C "1.6. In the Upper Design (GP) concept, the so-called "classification" is a set of definitions of types. The constraint of template parameters is actually a "type of time required", and it is also possible to make it a control with the concept of Interface in OOP: a class is required to implement an interface, can be said to be (IS-a) must Types of. There is no INTERFACE in C . [2], it can be expressed: a Class requires an Abstract Class to inherit an Abstract Class, which is the type defined by (IS-a) The Abstract Class defined. In Constrained Genericity, the template parameters need to meet a constraint, which can be instantiated. In the works of GP and STL, this is described in this manner: Template parameter (this is a type) called Model, which requires Constraint (a more abstract type) called Concept. More constraints for Model called Refinement. So, Concept-Model-Refinement can be compared with the Interface-Class-Inheritance. It is worth pointing out that Eiffel's parent Bertrand Meyer defines generics as type parameters in OOP Classic book Object-Oriented Software Construction 2 / E and believes in inheritance and polymorphism in generic technology and OOP: generics Describe the type relationship of the horizontal direction; and inherit will describe the type relationship in the vertical direction. (I have specific interpretations in the article "Selection and Learning of Wrist Program Design Language", see "Programmer" October 2001 and http://zmelody.myrice.com/articles/pl.htm. Bertrand believes that the generic method is a supplement to the classic OOP method, so it can also be included in the category of OOP. Differences in achieving, GP in C uses the geneative template implementation method. This is a method of spatial transfer time, so a large number of programs that use templates are often large, but the running speed is slightly OOP. Version; OOP uses a method of increasing an indirect layer to increase time overhead. There is also a point difference: OOP is a mature design method, interface, clas, inheritance, etc. have language elements, and many of GP lack language-level support.

What is lack of language level support? For example: If you read the STL source code, you might find such a definition similar: template void sort (RandomAccessIterator first, RandomAccessIterator last); template void sort (RandomAccessIterator first, RandomaccessItemizer Last, strictweakordering comp); there is no doubt that RandomaccessIitrator, stricTweakordering is constraint, or they are both first, the Last type requires the type (huh, is it very embarrassing). In the OOP language, whether the OO type matches the type of language / compiler to detect and guarantee the type mechanism of the language / compiler; but this GP code is just an identifier, in addition to telling the reader Constraint to the compiler outside the compiler outside the reader. Impact - You can use your editor to find and replace it into the word ForwardItemrator, you seem to have a big difference (the RandomaccessItemrator is ForwardIterator's Refinement), but the compiler does not care about this set. In fact, in a common template code, we often use "T" to indicate typeename - because this identifier is just a Place Holder, what is the Place Holder? Oh, the practice of your seating in the college self-study class is Place Holder, as for the ultimate use of this seat, of course, you. Since it is only occupied, why bother, theoretical, a thin draft book, a beautiful hard surface, a heavy-duty tank (if the chair is put on), the effect is the same. Template Void Sort (t first, t1); Template Void Sort (T1 First, T1 Last, T2 Comp); this changed code is changing from the compiler, And what is the programmer is clear or blurred? I don't know, everyone has a chapter.

Because the compiler doesn't care about this construint identifier (or not to say support for Constraint), the programmer will suffer a lot when the developer develops. Such a bitter is from looking for type errors from the early non-type language development procedures. For example, you will implement Sort operations for a container that doesn't support RandomaccessITerator, what happens? Try this code: #include #include using namespace std; int main () {list a; // some operation on a sort (a.begin (), a.end ()); When will I use this Operator? Why do I want to implement this Operator? It's really a fog. Maybe you will think that there is a mistake in the header file with the compiler, it will send a bug report to the compiler manufacturer. However, in fact, the error is really the reason for the Sort requires the type of parameters (oh, ok, formal saying is Concept) at least the randomaccessITerator, and the list :: Iterator is BidirectionAriTerator, not satisfied. But if there is no rich experience who knows this here? Which is as straight as a non-GP program?

So, ok, in order to make the GP method more easily, we have to let GP achieve products - such as STL - more complicated. For example, Concept Check Macro is such a technology. Both Boost and SGI STL provide such a macro. In fact, many technologies in GP are proposed to make up for the insufficient support of the compiler, such as Type Traits. Looking at the implementation of Concept Check, looking at Traits, I couldn't help but read the days of MFC source code. Early C language does not have RTTI support, nor has no abnormal handling mechanism; MFC is implemented by a series of macros; the C compiler provided by Microsoft for Windows CE embedded development is not supported by RTTI and exception processing, and it is called Fedor Sherstyuk The programmer wrote a TCU library (see Dani Carles, Adding Exceptions & Ratti to the Windows CE Compiler: Part I, DR. Dobb's Journal August 2002), hard is analog RTTI and exception handling. The programmer is really a creative group, they always become possible. So, will there be something lacking today, will it be added later? Will there be a new language that supports GP? I don't know, but I can see the "The Design and Evolution of C " and "STL's Parent Interview" I translated, some of the clues may be found. More instructions about constrained genericity, see "Bjarne Stroustroup's C style and technology" Chinese version [6], why I can't limit the parameters of the template. " Attached: [1] [2] Picking 我 的 "程序 程序 设计 设计 设计 选择 选择 与", [3] [4] [5] Translated from "Object Unencapsulated: Eiffel, Java and C " 1.6 (authorized), [6] Translated from Bjarne Stroustrup's C Style and Technique FAQ (authorized).

[1] Object-oriented programming provides two methods to generate new complex types: Hierarchy and Composition. Two examples, wood flammable, then the chair made by the wood can also be burned. This is inheritance. Fruit can be eaten, then fruit platter can be eaten naturally. This is a combination. In fact, it is now strictly called Type Oriented Programming. An Object is just a type (Type, often Class Class, but remembers the two concepts not equivalent), but the center of focus of OOP is design / abstract good class, reasonably divided Function, this is the work on the type level instead of work on the object level. Especially C , its data package is class-based, which means that different instances of the same class (which are different objects) can access each other's private data members. For example: Class a {private: int Z; Void F (A & a) {z = a.z;}}; and this is not allowed in some stringent OO languages. "Private" is privately located in the object. An object requires private information that access another object must pass the public interface.

[2] Class in C is not the peer of TYPE. There is a paragraph of "C : Effective Object-Oriented Software Construction" in Kayshav Dattatri and Erich Gamma to explain the meaning of modern "Type". A class can be several types at the same time as it implements (Implement) of these Type's Interface. Similarly, several Class can be a type of TYPE as long as they achieve the same interface. However, C does not independently and clear Interface concept, so C is not the most OO language, nature is not the language that is best for teaching. Java is better than it. [3] We complete the syntax check by checking if the language we use is in line with the usual cognition. For example, "he has a computer, starting a cup of coffee." This sentence is not a little wrong from the angle of grammatism, but even the primary school students will laugh at this bullhead and do not have a nonsense, which violates our computer and A typical cognition of a cup of coffee. Using object-oriented programming terms, errors lies in the computer's "type" with no "drinkable" properties. Therefore, when writing a program, we must try to avoid similar errors, so that the type of programming language is not allowed to check the role of such errors.

[4] C is a static type language, but we have many means to make the program with the flexibility of dynamic types and the type of language, which means that we can force the compiler to ignore the powerful constraint of the type system, and let Some special programs are compiled. This is like, sometimes we have to force the poor "drinking" his computer, and if this person needs to be sent to the hospital, it is another code. To know, this occasional exceptional language is not allowed to lack flexibility. In order to do this, we need to change the property, that is, the computer is a drink: o) We should not veto the entire type system, but allow for flexibility to allow a small latter door in the type system.

[5] OO language provides two specific ways to generate new complex types: combination and inheritance. The most important feature of the OO language may be its facing-oriented characteristic. In fact, the future of objects should be a type, or "object-oriented" should be "targeted". Typeful point is how to define new types; how to use existing types to derive more new types --oo language provides parallel inheritance and generic; how to go to designated type Inheritance relationship. In a type-oriented system, we need a specification to define a new type, a rule to merge an existing type. Once the type is a psychological setting, or culture, our previously defined type rules will be more extensive.

[6] Q: Why can't I limit the parameters of the template? A: Hey, in fact, you can be. And this kind of practice is not difficult, and it doesn't need to exceed routine skills. Let's see this code: Template Void Draw_all (container & c) {for_each (c.begin (), c.end (), mem_fun (& shape :: draw));} If c does not conform to Constraints, Type errors, the error will occur in fairly complex for_each parsing. For example, the type of parameterization is required to instantiate the INT, then we cannot call Shape :: Draw (). The error message we get from the compiler is confusing - because it is unclear with complex for_each in the standard library. In order to capture this error earlier, we can write code: Template Void Draw_all (container & c) {shape * p = c.front (); // accept Only Containers of Shape * S for_each (c.Begin) ), c.End (), MEM_FUN (& Shape :: DRAW));} We noticed that the definition of Shape * P in front (although the program itself, P is useless). If you cannot assign C.front () to Shape * P, then we can get a meaningless error message for most modern compilers. Such skills are common in all languages, and they have to be true for all "unusual structures". [Translation: It means that for any language, when we start to explore the limit, then have to write some highly skillful code. This is not the best. If you want me to write the actual code, I may write this: template void Draw_all (container & c) {typedef typetename container :: value_type t; can_copy (); // accept containers of onlyly Shape * s for_each (c.begin (), c.end (), mem_fun (& shape :: draw);}

This makes the code universal and obviously reflects my intent - I am using assertions [注] TypenAme Container is the type of container accepts that the TypenAme Container is accepted, not confused to define a shape * pointer, I don't know where it will be used later]. CAN_copy () template can be defined: Template struct can_copy {static void constraints (t1 a, t2 b) {t2 c = a; b = a;} can_copy () {void (* p) (T1, T2) = constraints;}}; can_copy inspections during compilation T1 can be paid to T2. CAN_copy Check that the confirmation T is a shape * type, or a pointer to the public inheritance class pointing to the Shape, or the user-defined type of type of Shape *. Note that the implementation of CAN_COPY () here is basically optimized: a row code to indicate the constraints you need to check [Translation: Refers to the first line code; constraints is T2], and to do this type of check to this check [ Translation: The type of check is T1]; a row code is used to accurately list the constraints (constraints () function to check if it is satisfied [translation: 2 clauses, there are 2 clauses, but there are Reason. If T1, T2 are user-defined classes, then t2 c = a; detection can be default; b = a; detection can be copied to construct; a row code is used to provide opportunities to perform these checks [Translation: Chapter 3. CAN_copy is a template class; constraints is its member function, and the second line is only defined, not executed.

[Translation: The key to Constraints implementation here is to rely on C powerful type systems, especially the polymorphism of the class. T2 c = a; b = a; B = a; the condition that can be used is: T1 implements T2 interface. Specifically, it may be the following four cases: (1) T1, T2 is the same type (2) Overload Operator = (3) Provide a Cast Operator (Type Conversion Operator) (4) Derivative class object assignment to the base class pointer . Speaking here, I remember that I have said in an article, C Genericity actually - TMPLATE does not support constrained genericity, while Eiffel supports constrained genericity from the grammatical level (ie providing similar to Template XXX Syntax Such a syntax - where Compraready is a constraint. Readers have pointed out that I said that C Template also supports Constrained Genericity. Now this part of this translation gives the use of some techniques, combining OOP and GP methods, thereby homogenerate constrained genericity methods in C . This technique is worthy of fine taste for readers with hobby C . However, don't lose global vision because of the code skills of the various sub-branches. Sometimes lack of language support can make up for more elegant design levels (rather than code levels). In addition, this can be considered "C Template support constrained genericity", I reserve comments. As, use c to use some tips to OOP, but we don't say C language support OOP. ]

Please pay attention to it, now our definition has these features we need: You can express the consTRAINTS [Declarant: Equivalent Definition / Copy variable "in the CAN_COPY Template without the definition / copy variable. It is assumed that any "That type is this initialization", and it is not necessary to copy whether the object can be copied, destroyed (unless this is construining). [Translation: ie - unless Constraints is "copied", "can be destroyed". If you use easy-to-understand pseudo code, it is Template XXX, Template xxx. ] If you use a modern compiler, Constraint does not bring any additional code definitions or use constraint without using macro definitions If constraint is not met, the error message given by the compiler is easy to understand. In fact, the given error message includes the word "constraints" (in this way, the coder can get a prompt), the name of Constraints, the specific error reasons (such as "Cannot Initialize Shape * By Double *") is this, we Do you not simply define a sympathy similar to C language itself? The Design and Evolution Of C analyzes the difficulties of this practice. There have been many design philosophy to float the water, just to make the Constraint template class easily write, but also give an error message that is easy to understand when Constraint is not satisfied. For example, I am from "using the function pointer" in can_copy from Alex Stepanov and Jeremy Siek. I think my CAN_copy () does not still have a standardized extent - it needs more practical inspections. In addition, C users encounter many different types of constraints, which seems to have no forms of Constraints to get overwhelming. There have been many "Built-in Language Support" schemes for Constraints to be proposed and implemented. But actually to express consTraint does not need any exotic thing: After all, when we write a template, we have a strong expression of the C brings us.

Let the code test for my words: Template struct derived_from {static void constraints (t * p) {b * Pb = p;} Derived_From () {void (* p) (t *) = Constraints;}}; template struct can_copy {static void constraints (t1 a, t2 b) {t2 c = a; b = a;} can_copy () {void (* p) (T1, T2 ) = constraints;}}; template struct can_compare {static void constraints (t1 a, t2 b) {a == b; A! = B; a STRUCT CAN_MULTIPLY {Static Void Constraints (T1 A, T2 B, T3 C) {c = a * b;} can_multiply () {void (* p) (T1, T2, T3) = constraints;}}; struct d: b}; struct d: b {}; struct dd: d {}; struct x {}; int Main () {DERIVED_FROM (); Derived_From (); Derived_From (); Derived_From (); derived_from (); can_compare (); can_compare (); can_multiply (); can_multiply (); can_multiply (); can_copy (); CAN_COPY (); can_copy ();

} // The classical "elements" constraint: Template Class Container: Derived_From {// ...}; in fact derived_from does not check inheritance Convertibility. But Derive_From is often a better name - sometimes giving constraints a good name is also a lot of things that require detail. Last Revision: 2002.7 If you want to reprint, please contact me: zMelody@sohu.com