JP2006302303A - Method for operating or accessing object of computer system and string class - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To reduce code and cycle overhead concerning a text string operation in the case of describing an operating system in an object oriented language C++. <P>SOLUTION: An object oriented operating system handles all objects related to text strings as belonging to one of three classes, in which each class performs a different function and at least one such class is modified to do so in a way that reduces code and cycle overhead. This minimizes executable code overhead to minimize the amount of memory required, and allows execution in a minimum number of cycles to minimize power consumption. The operating system is particularly well suited to ROM based mobile computing devices. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to improvements in object oriented operating systems for computers. The invention particularly relates to an operating system based on C ++ programming techniques. A commercially available embodiment of this operating system is the EPOC32 operating system manufactured by Psion Software Plc, UK. The EPOC 32 is an operating system suitable for a mobile computer environment.

The C ++ language is widely used to describe application programs for computers such as personal computers, but is rarely used to describe operating systems. When writing an operating system for a personal computer, the requirement of minimizing the size of executable code or minimizing the number of cycles required to execute a step in a program is usually not preferred. In general, performance and ease of description are more important requirements.
Nothing in particular

  However, in other situations, the space occupied by executable code must be minimized (eg, to minimize power consumption) (eg, to minimize the capacity of the ROM and / or RAM that stores it). May need to be executed in a minimum number of cycles.

  Mobile computing (eg personal digital assistant: PDA), smart phone (eg GSM cellular phone with built-in word processor, capable of sending and receiving facsimiles and browsing the Internet) and network computer (NC) environment is an operating system code An example of an environment where minimizing size is an advantage. That is, minimization can mainly reduce hardware (especially ROM and / or RAM) costs. This is particularly important in the above situation, since a wide range of consumer applications generally rely on relatively low cost hardware. Similarly, in the category of mobile computing and smartphones, minimizing processor execution cycles is very important because it minimizes power consumption and minimizing power consumption is essential to extending battery life. It is. A well-designed operating system written in C ++ is usually quite large and consumes considerable power. This is therefore not suitable for mobile computing, smartphones and NC environments.

  In addition, it is generally considered difficult to design a fully functional operating system in C ++ that meets the stringent requirements of code size and overhead cycles, especially the demanding requirements of mobile, smartphone and NC computing environments. It has been.

The term "string class object"
In C ++, text (eg, a string of characters that actually appears on a computer screen) is represented as an “object”. Those skilled in the art of C ++ or other object-oriented languages will be familiar with this categorization. Such text-related objects are of a specific type called “string class objects”. The type of class to which the object belongs (eg, a string class in the case of text) defines the operations that are allowed to be performed on the object. Only certain operations can be performed on a string class (for example, two text strings are connected together). Thus, a particular object of the string class represents a specific text string. It is only operated in a specific, well-defined way.

  In order to create a string class object from an item of text when the text is present in a filing system file, the following steps are performed in conventional C ++ programming.

• Shift the buffer position in memory. • Use the file read service to read the text into the buffer. • Use the string generation service to convert the buffered data into a string class object. • Discard the contents of the buffer. Although it is difficult to identify the actual storage location of the string, it is not necessary to know the location of the text string. Because it is a string class object that directly manipulates, the actual text string is manipulated as a result. Thus, a string class object knows virtually the memory location of a text string and can handle all of the necessary memory management tasks associated with text manipulation.

Multiple classes of objects of the string class In the C ++ version known as the ANSI / ISO C ++ standard draft, all objects of the string class (strings in the standard part of the standard library draft referred to as <string>) Processed in such a way that sophisticated memory management tasks can be performed (as exemplified by the class) (eg, buffer space can be expanded, reduced, combined, ie fully dynamic) Relocation of buffer space for text). However, this level of memory management uses a large amount of code and requires a significant amount of space.

  Here, two examples of conventional C ++ memory management are shown.

Example 1: C ++ literal text processing In C ++, there are many instances where the source code contains a text string. These text strings are known as “literal text” and are literally stored in buffer memory when the source code is compiled into executable object code. When literal text is manipulated, a string class object must be created from it. However, by creating this string class object, a text string is created in memory, and this text string is actually manipulated by the newly created string class object. In short, the text string is duplicated in memory. That is, the text string is generated once in the original buffer resulting from the compilation of the source code, and is then duplicated again at the memory location associated with the string class object that allows the manipulation of the text.

  As mentioned above, code space and power consumption are important in certain computer environments. However, conventional C ++ (as implemented in the ANSI / ISO C ++ standard draft) does not have a mechanism to eliminate the inherent duplication of literal text. This is particularly a problem with operating systems, as the operating system often has to deal with literal text.

Example 2: Processing text with limited C ++ length In C ++, a programmer uses heap memory to process text. Text with limited length does not actually require the sufficiently flexible approach needed to process text with unlimited length. Nevertheless, with conventional C ++, there is only a sufficiently flexible mechanism well characterized for string class objects, and no other mechanism, regardless of the length of the text. This increases the overhead in the memory management code because heap memory handling is code and cycle intensive.

  Text memory management across C ++ uses code and cycles intensively. Since code space and power consumption are important in a mobile environment, the conventional C ++ approach results in an operating system that has an unacceptably large code size and consumes a large amount of power.

  The operating system of the present invention replaces a string class object (eg, as defined in the ANSI / ISO C ++ standard draft) with a triple structure of string class objects, mainly three new object classes. Redefine it. Traditionally well-characterized memory management functions that are functionally related to <string> according to the draft ANSI / ISO C ++ standard do not apply to all three new classes. Although well-functioning is useful in many environments, it is a problem (among others) in mobile computing environments where code space and power consumption are important.

  Thus, the generalization of the inventive concept of the present invention allows the computer operating system to have three different classes dealing with text strings: three different classes, each of which is suitable for a different situation, Is to minimize code size and cycle overhead. This gives flexibility. That is, for example, a memory management function that performs all functions can now be applied only to text strings that actually need it.

  This new string class object family will be referred to as a “descriptor”. In the preferred embodiment, members of this family are referred to as “pointer descriptors”, “buffer descriptors” and “heap descriptors”. It should be noted that these concepts are different (although related) to the established concepts of “pointers”, “buffers” and “heaps” familiar to those skilled in the art. Also note that the descriptors envisioned herein have nothing to do with the VMS facility of the same name or the small integer UNIX® term used to identify the active operating system. is required. One skilled in the art will appreciate that an operating system can be designed to have more than three classes that handle text strings. Such modifications are also included in the scope of the present invention. The triple structure is the least (and most effective in almost all cases) as a propagation of classes.

  Furthermore, the descriptor is preferably polymorphic, so a single service operates on all descriptors. This results in significant code and lesser overhead reduction since each different descriptor requires a differently modified service.

  According to a first aspect of the present invention, a computer programmed with an object-oriented operating system configured to handle objects related to text strings, wherein the operating system changes all of the objects to different ones. Perform functions and treat as belonging to one of three classes (mainly pointer descriptor class, buffer descriptor class and heap descriptor class), at least one of which has been modified to reduce code and cycle overhead A computer characterized by this is provided.

  In order to significantly reduce code and cycle overhead, the present invention replaces a conventional single form string class object with (for example) three different form objects, each form optimized for different situations. Is based on the knowledge that the operating system needs to be redesigned.

  In the preferred form of the present invention, conventional memory intensive text processing techniques apply only to objects that belong to a new descriptor class (ie, heap descriptor) that defines objects that require such techniques. The However, the pointer and buffer descriptor classes are designed to reduce code and processor cycles compared to conventional string classes.

  Using the two examples described in the above prior art (ie, Example 1: C ++ literal text processing and Example 2: C ++ length limited text processing), the operating system of the present invention: (I) treats literal text to eliminate the need for duplication of literal text, and (ii) is dynamically determined at runtime to perform intensive use of heap memory code only in the limited circumstances actually required In other situations (eg when the programmer knows the maximum length of the text in advance), use static memory instead to handle the text. Further details of the specific process are given below.

  Preferably, the operating system is configured to handle not only text but also raw data using the same triple structure.

  In addition to the computer / operating system combinations defined above, other progressive aspects could be handled as well. For example, any device that must interface with such an operating system must use the same triple structure for string class objects. For example, peripheral device driver software such as a solid-state memory device needs to use this triple structure. The software for the peripheral device control panel is the same.

  Accordingly, in a second aspect of the present invention, there is provided a computer peripheral device programmed with an object-oriented operating system configured to handle objects related to text strings, wherein the operating system receives all of the objects respectively. Belongs to one of three classes (mainly pointer descriptor class, buffer descriptor class, and heap descriptor class) that perform different functions, at least one of which has been modified to reduce code and cycle overhead A peripheral device is provided, characterized in that the peripheral device is programmed to treat the object as if it were in the three classes.

  In a third aspect of the present invention, a computer operating system configured to handle objects related to text strings and encoded on a computer readable medium, the operating system comprising: In one of three classes (mainly pointer descriptor class, buffer descriptor class, and heap descriptor class), each executing a different function, at least one of which has been modified to reduce code and cycle overhead An operating system is provided which is characterized as being treated as belonging.

  According to a fourth aspect of the present invention, there is provided a method for operating a microprocessor using a computer operating system configured to handle objects related to text strings, wherein the operating system includes: Belongs to one of three classes (mainly pointer descriptor class, buffer descriptor class, and heap descriptor class) that perform different functions, at least one of which has been modified to reduce code and cycle overhead A method is provided that is characterized as being treated as a thing.

  In a fifth aspect, a computer-readable medium encoded with a computer operating system configured to handle objects related to text strings, wherein the operating system includes all of the objects, each Those that belong to one of three classes (primarily pointer descriptor classes, buffer descriptor classes, and heap descriptor classes) that perform different functions, at least one of which has been modified to reduce code and cycle overhead A medium characterized in that it is treated as is provided. Typically, the computer readable medium is a mask ROM. For distribution, the medium may be a general CD-ROM or floppy disk.

  The present invention will be described with respect to an embodiment known as EPOC32. EPOC32 is a 32-bit operating system (particularly) for mobile and smartphone environments developed by Psion Software Plc, UK. A more detailed description of the EPOC32 embodiment is disclosed in the part attached to Appendix 1 of the SDK for EPOC32 published by Psion Software Plc, UK. To the extent that the rights of the inventor and assignee are not limited in any way, the entire SDK is incorporated herein by reference.

  The EPOC 32 has been ported to run on a number of different microprocessor architectures. Details of operating system porting are essentially outside the scope of this specification, but will be appreciated by those skilled in the art. In particular, EPOC32 has been ported to the ARM RISC type microprocessor of Advanced RISC Machines in the UK. Various models of ARM microprocessors are widely used in digital cellular telephones and are well known to those skilled in the art. However, the present invention can be implemented on a number of different microprocessors. Accordingly, the claims herein should be understood to cover any and all hardware and software implementations in which the operating system performs the functions as recited in the claims.

  Returning to the example of literal text and limited-length text given in the prior art discussion above, EPOC 32 uses the triple structure for string class objects as follows.

Example 1: Literal Text in EPOC32 As mentioned above, in conventional C ++, the text string for literal text is duplicated in memory. That is, it is generated once in the original buffer that results from the compilation of the source code and then replicated again at the memory location for the string class object that allows the manipulation of the text. This duplication is useless.

  However, EPOC 32 uses a pointer descriptor that points to the original memory location of the literal text (ie, the memory location defined by the compiler). This pointer descriptor (referred to as TPtrC pointer descriptor in EPOC32) is a string class object for literal text. (In C ++, a pointer is essentially not recognized as a normal object.

  Thus, the EPOC32 pointer / object hybrid completely eliminates the need for additional copies of literal text.

Example 2: Text with limited length in EPOC32 As noted above, conventional C ++ only has a mechanism to use sufficiently flexible and well-characterized string class objects, regardless of the text length. There is no mechanism to use other than that. Since heap memory processing is code and cycle intensive, this creates a lot of overhead in the memory management code.

  In EPOC32, there is a special class for string objects called size limited buffer descriptors. Since they are limited in size, they do not require complex memory allocation code to operate. Furthermore, the buffer descriptor can use static memory (not heap memory). Static memory is more efficient to use because it requires less code cycles to perform the necessary operations, although it cannot relocate memory in a way that uses heap memory intensively. (Thus power savings). The EPOC 32 uses heap memory with a lot of cycle overhead only if it is actually dynamic. In that case, heap descriptor class is used.

The EPOC 32 defines a string class parameter with a limited length using a class template of the “TBuf” class. (A class template defines the properties of a number of objects of a string class. For example, TBuf is a template for all objects of a string class of all buffer descriptors, ie, buffer variants. TBuf is such a string class such as Define certain common properties for objects.)
EPOC 32 also exhibits important features other than minimizing code size and cycle overhead. The main points are as follows.

String and raw data buffer class objects that operate as a “flat” structure • Polymorphic properties given by the descriptor • String and raw data as a flat structure where the descriptor allows uniform coding of Unicode and ASCII Buffer class objects All descriptors have a “flat” structure (ie, when a descriptor is copied, only the descriptor itself is copied. In conventional C ++, a copy of an object is not just the object itself, but all related objects. There is also a need for a copy of the pointer and the data pointed to, that is, a complex related structure that gives meaning to the object.) Thus, in EPOC32, copying descriptors is much more economical in memory overhead and cycles than copying objects that are equivalent in normal C ++.

  This is achieved in EPOC 32 for buffers and pointers as follows.

  The buffer descriptor (TBuf) contains the actual text referenced by the buffer, so copying the buffer essentially copies the associated text. There is no need for a copy of the pointer and associated data as in C ++.

  Since the pointer descriptor (TPtr) contains a C ++ type pointer, only TPtr is required when copying. In conventional C ++, it was necessary to copy not only one entity but also other related pointers and text.

Descriptors as polymorphic objects A group of objects is said to exhibit polymorphism when all objects in the group act like a single object, even though common actions are achieved by different mechanisms. Polymorphism is brought about by a virtual function in conventional C ++, where all objects that are polymorphic to each other contain a pointer to a virtual function table (and thus a pointer is needed in each object) at a common location. . This table identifies the actual code for each polymorphic function. A separate table is required for each class that shares polymorphism. However, this approach uses a relatively large space because each pointer is 32 bits (ie 4 characters) and each object requires a pointer to a virtual function table. In addition, a 32-bit long field is used in each object.

  In the mobile operating system environment (especially) this is a problem. In EPOC32, the string class object is handled as follows. That is, a 32-bit long field is subdivided, and the first 4 bits describe the descriptor type. The function then examines the 4 bits and points to the correct text position (eg, if the descriptor is a buffer, in the descriptor itself). Thus, each of the three different classes of descriptors for string class objects (ie, pointer descriptor, buffer descriptor, and heap descriptor) can be described using only the first 4 bits of a single 32-bit field. Provides polymorphism. In this way, considerable memory savings are achieved. More generally, a field shares a machine language with another data item.

Unicode and ASCII unchanging code In C ++, 16-bit Unicode coding would double the size of all text data that would otherwise be 8-bit code. Conventionally, when a programmer writes source code, it has been necessary to decide whether to use ASCII or Unicode.

  In EPOC32, the same source code is used regardless of the final choice of ASCII or Unicode. This is accomplished by configuring the system with class name aliases that are not changed by ASCII and Unicode, but by the classes themselves (eg, pointer descriptors, buffer descriptors and heap descriptors). Thus, instead of using the pointer TPtr16 to describe Unicode or using TPtr8 to describe ASCII, the programmer creates it using the TPtr class name.

  At creation time, class names can be compiled in either 16-bit Unicode or 8-bit ASCII code. This approach can be applied to include all character sets encoded with different bit lengths.

Supplementary Benefits of EPOC32 In C ++, text strings usually end with “0”, which allows the system to easily know where the text string ends. In EPOC32 this is no longer necessary. This is because the descriptor includes a description that defines the length of data to be referred to. This eliminates the need to use "0" to indicate the end of each text item, further saving code.

Summary of descriptor features There are three classes of descriptors. That is, a pointer descriptor, a buffer descriptor, and a heap descriptor.
There are two types of pointer descriptors. An invariant pointer descriptor TPtrC and a variable pointer descriptor TPtr.

Invariant pointer descriptor: TPtrC
-Data cannot be changed by this.
・ All member functions are constant.
Invariant strings or data (eg data that must not be changed)
Derived from TDesC and thus has a large number of member functions.

Variable pointer descriptor: TPtr
-Data can be changed by this descriptor as long as the maximum length set by the designer is not exceeded.
Directly point to the memory area that contains the area that has been changed.
-The number of data items included is determined by the pointer length.
-TDes for changing and manipulating data in addition to all TDesC member functions-The pointer descriptor is separate from the data representation, but consists of pre-existing areas in memory.

  There are two forms of buffer descriptors.

Invariant buffer descriptor: Tbuf <;TintS>;
-Data can be set in the descriptor at the time of creation or later by an assignment operator (operator =).
• The length is defined by an integer template. That is, TBufC <;40>; includes 40 data items.
Inherit all TDesC member functions.

Variable buffer descriptor: Tbuf <;TintS>;
-Data that can be changed within the range not exceeding the maximum length is included.
• Maximum length defines the maximum number of data items.
• The actual length defines the actual number of data items.
• The length is defined by an integer template. That is, TBuf <;40>; contains only 40 data items.
The data area is a part of the descriptor object.
It is useful for including data that needs to be manipulated and changed, but its length does not exceed a known maximum (eg WP text).
Inherit all TDesC member functions plus TDes member functions for data modification and manipulation.

-There is only one form of heap descriptor.
Invariant heap descriptor: HBufC
• Consecutive length with data.
The data area is a part of the descriptor object, and the entire object occupies cells allocated from the heap.
-Data can be set in the descriptor at the time of creation or later by an assignment operator (operator =).
Inherit all TDesC member functions.
Reassignable, ie the data area can be expanded and contracted.

Appendix 1
Pslon Software Plc. EPOC32 “Descriptor” SDK (excerpt) to be issued in 1997. Pslon Software Plc. Refers to the entire SDK published in July 1997 (Revision 1.0).

_____________________________________________________
SDK: Descriptor Overview The triple structure of descriptor classes (mainly pointer descriptor class, buffer descriptor class and heap descriptor class) is safe for both strings and general binary data, regardless of the type of memory in which they reside. And provide a mechanism for consistent access and operation. For example, the code part string in the ROM can be handled in the same manner as the file record in the RAM.

  The data represented by the descriptor is in a data area at a predetermined position in the memory. This data area cannot be expanded. Manipulation of descriptor data is safe in the sense that accidental or deliberate memory access outside of a defined data area is not allowed (generally code that makes invalid accesses is an exception (usually known as panic) Cause).

  Since descriptors do not differentiate by the type of data represented, both string and binary data are treated similarly. Although some of the descriptor object member functions are designed to manipulate text data, they also work on binary data. This unifies the handling of strings and binary data and increases efficiency by allowing code to be shared.

Descriptor classes satisfy several important requirements:
Provide support for both Unicode and ASCII text. The macro UNICODE is used to select variables created in ASCII or Unicode.
・ Unify handling of strings and binary data.
Enables safe and convenient reference of text or data in ROM.
Provides a number of member functions that operate on related text or data.
• Allows data modification, but prevents any attempt to write outside the defined data area.
Eliminate memory overhead associated with virtual functions.
It acts like a built-in type, can be created safely on the stack and can be safely orphaned.
(HBufC is allocated on the heap and is an exception to the rule).

_____________________________________________________
ASCII and Unicode text E32. Descriptor character set ASCII text characters are represented by 8 bits (1 byte), while Unicode characters require 16 bits (2 bytes). To support both ASCII and Unicode text, the descriptor class has two variants, 8-bit and 16-bit. For example, there are two pointer descriptor classes, TPtr8 and TPtr16.

  The program can be configured to support either Unicode or ASCII text using a class name that is independent of the created variable. For example, the descriptor class TPtr can be used to configure the system to use either TPtr8 or TPtr16. It is determined at the time of creation (build time) depending on whether or not the macro UNICODE is defined.

  Header file E3232def. The following code extracted from h (see Appendix 1 of the SDK) shows how to achieve it by properly defining class names independent of variables.

#If defined (UNICODE)
...
typedef TPtr16 TPtr;
...
#Else
...
typedef TPtr8 TPtr;
...
#Endif

  Application code should not use "C" style string literals directly. Instead, the macro S should be used to return the appropriate type of pointer to generate the appropriate width “C” style string. Also, macro L (L for "literal") should be used to create the appropriate type of descriptor. For definitions of these macros, see e32. macro. _S and e32. macro. See _L.

For example,
const TText * str = _S (“Hello”);
Generates a string of 1-byte characters created in ASCII, but generates a string of 2-byte characters in Unicode creation.

_L (“Hello”);
Generates an 8-bit descriptor created in ASCII and a 16-bit descriptor created in Unicode. For example, _L (“abcdef”) is always used instead of plaintext “abcdef” so as to always create a correct variable descriptor.

  By using macro_S8 and macro_L8, respectively, an 8-bit “C” style string and an 8-bit pointer descriptor are explicitly generated independent of the created variables. Corresponding 16-bit versions, _S16 and _L16 can also be used. For these definitions, see e32. macro. _S8, e32. macro. _L8, e32. macro. _S16 and e32. amcro. See _L16.

_____________________________________________________
Length and size E3232. Descriptor length and size A descriptor characterizes the data it represents by the length of that data. The length of the descriptor is the number of data items. For an 8-bit variable, the descriptor length is the number of 1-byte data it represents, and for a 16-bit variable, the descriptor length is the number of 2-byte data it represents.

  Descriptor size is the number of bytes occupied by descriptor data, and need not be the same as the descriptor length. For an 8-bit variable, the size is the same as the length, and for a 16-bit variable, the size is twice the length. A descriptor that allows data to be modified is also characterized by its maximum length. For these descriptors, the length of the data represented can vary with a maximum value from zero to this maximum value. The maximum length of any descriptor is 228.

_____________________________________________________
Text and binary data E3232. In discrete text and binary “C”, strings are characterized by requiring a zero terminator to indicate the end of the string. These cause a number of problems. In particular, they cannot contain binary data (if the data contains binary zeros) and operations on them are generally not efficient. “C” strings need to be handled differently from binary data, as reflected in the ANSI “C” library function group, memxxx () and strxxx (). Descriptors allow string and binary data to be represented in the same way, which allows the same function to be used in both cases. For binary data, an 8-bit descriptor must be explicitly used. For binary data, the distinction between Unicode and ASCII is meaningless. Note that 16-bit binary data is virtually unused.

_____________________________________________________
Memory allocation E3232. Descriptor Assignment Descriptor classes (except HBufC) act like built-in types. They do not allocate memory and have no destructors. This means that descriptor classes can be isolated on the stack as well as built-in types. This is especially important in situations where you can leave code. (See E3232. Exception trap. Cleanup. Requirements for the impact of isolation)
The HBufC descriptor object is allocated on the heap and is not created on the stack.

_____________________________________________________
Exception E3232. Descriptor Exception All parameters of the descriptor member function are examined to ensure that the operation is correctly specified and no data is written outside the descriptor's data area. The particular result is that no member function can extend a variable descriptor beyond its maximum allocation length. Depending on whether the original allocation is large enough or a larger descriptor is dynamically allocated at runtime in anticipation of the need for larger descriptors, ensuring that all descriptors are large enough to accommodate the data is It is the responsibility of the programmer. Although the static approach is easier to implement, the dynamic approach may be more effective in certain cases where it turns out to be useless. In the case of exceptions, it is considered safe not to perform any unauthorized memory access and to prevent any data from being moved or damaged.

_____________________________________________________
Descriptor type E3232. Descriptor types There are three types of descriptor objects.

That is,
Pointer descriptor A descriptor object is created in a pre-existing area in memory, although it is separate from the data it represents. This includes
Immutable pointer descriptor, TPtrC
Variable pointer descriptor, TPtr
There are two forms.

Buffer descriptor The data area is a part of the descriptor object. This includes
Immutable buffer descriptor, TBufC <;TlntS>;
Variable buffer descriptor, TBuf <;TlntS>;
There are two forms.

-Heap descriptor The data area is a part of the descriptor object, and the entire object occupies cells allocated from the heap. this is,
Immutable heap descriptor, HBufC
There is only one form.

_____________________________________________________
Pointer descriptor-TPtrC
E3232. Descriptor pointer descriptor. TPtrC
TPtrC is an immutable descriptor that does not change any data. All of its member functions are constant (except for constructors). FIG. 1 schematically shows TPtrC. TPtrC is useful for referencing immutable strings or data, for example, when accessing text generated in ROM resident code, or passing a reference to data in RAM whose data must not be altered by that reference. . TPtrC is derived from TDesC, which provides a number of member functions that manipulate its contents, such as, for example, the positioning of characters in the extracted portion of text or data.

_____________________________________________________
Pointer descriptor-TPtr
E3232. descriptor. Pointer descriptor. TPtr
TPtr is a pointer descriptor that can change data within a range in which the data does not exceed the maximum length. The maximum length is set by the constructor.
TPtr points directly to the area in memory that contains the data being changed. TPtr is shown schematically in FIGS. 2A and 2B.

  The maximum number of data items that an area can contain is defined by the maximum length. TPtr represents how many data items are currently included in the data. When this value is smaller than the maximum value, a part of the data area is unused. TPtr generates a reference to an area of RAM that contains data that is intended to be modified by reference, or to a RAM area that has no data yet, but uses descriptor references and member functions to generate data It is effective to do.

  TPtr is also useful for generating a reference to a TBufC or HBufC descriptor that contains the data being modified. TPtr used in this way points to a TBufC or HBufC descriptor. The data contained in the TBufC or HBufC descriptor can be changed by TPtr. TPtr is derived from TDes derived from TDesC. Therefore, TPtr inherits all the const member functions defined in TDesC, as well as the TDes member functions that can manipulate and modify data, such as adding characters to the end of existing text. .

_____________________________________________________
Buffer descriptor-TBufC <; TInt S>;
E3232. descriptor. Buffer descriptor. TBufC
TBufC is a buffer descriptor having a length followed by a data area. Data is set in the descriptor by an operator (operator =) assigned at generation time or at any other time. The data held by the descriptor is unchanged. TBufC is schematically shown in FIG. The length of TBufC is defined by an integer template, for example, TBufC <;40>; defines TBufC that can contain up to 40 data items.

  TBufC is derived from TDesC, which provides a number of member functions that manipulate its contents, for example, locating characters in the text or data extractor. TBufC provides a member function Des () that creates a variable pointer descriptor (TPtr) that references TBufC. As a result, the TBufC data can be changed by TPtr as schematically shown in FIG. The maximum length of TPtr is the value of the integer template parameter.

_____________________________________________________
Buffer descriptor-TBuf <; TInt S>;
E3232. descriptor. Buffer descriptor. TBuf
TBuf is a buffer descriptor including data that can be changed within a range in which the data does not exceed the maximum length. FIG. 5 schematically shows TBuf. The number of data items that TBuf can contain in the internal data area is defined by the maximum length.

  The length of the descriptor indicates how many data items are currently included in the data area. When this value is smaller than the maximum value, a part of the data area is unused. The maximum length of TBuf is defined, for example, by an integer template such that TBuf <; 40>; defines a TBuf that can contain up to 40 (and no more!) Data items. TBuf is useful for accommodating data that requires manipulation and modification, such as word processor text, but whose length does not exceed a known maximum. TBuf is derived from TDes derived from TDesC.

  Therefore, TPtr inherits all the const member functions defined in TDesC, as well as the TDes member functions that can manipulate and modify data, such as adding characters to the end of existing text. .

_____________________________________________________
Heap descriptor-HBufC
E3232. descriptor. Heap descriptor. HBufC
HBufC is a descriptor having a length followed by a data area. It is allocated on the heap using the static member function, New (), NewL () or NewLC (). The descriptor length is passed as a parameter to these static functions. FIG. 6 schematically shows HBufC. Data is set in the descriptor by an operator (operator =) assigned at generation time or at any other time. HBufC is derived from TDesC, which provides a number of member functions that operate on its contents, for example, locating characters within the text or data extractor.

  HBufC provides a member function Des () that creates a variable pointer descriptor (TPtr) that refers to HBufC. The maximum length of TPtr is the length of the HBufC data area. FIG. 7 schematically illustrates this.

  Heap descriptors can be relocated. The function ReAlloc () or ReAllocL () enables expansion or contraction of the data area of the heap descriptor. However, the length of the data area cannot be shorter than the length of data currently held. Before reducing the data area, the data held by the descriptor must be reduced. The length of data that can be set in the heap descriptor by the allocation operator is limited to the space allocated to the data area of the descriptor. The memory occupied by the heap descriptor needs to be explicitly freed using a call to User :: Free () or the keyword delete.

_____________________________________________________
Descriptor class inheritance / derivation relationship E32. descriptor. Class All descriptor classes, TPtrC, TPtr, TBufC, TBuf and HBufC are derived from the abstract base classes TDesC and TDes.

  The class TBufCBase has been shown as an abstract base class, simply because it is easy to implement. FIG. 8 schematically shows the relationship between classes.

  The action of the actual descriptor class is very similar, so most functions of the descriptor are provided by the abstract base class. Since descriptors are widely used (especially in the stack), it is necessary to minimize the size of descriptor objects. To assist this, the virtual function is not defined in order to eliminate the overhead of the virtual function table pointer in each descriptor object. As a result, the base class potentially has knowledge of the classes derived from it.

  E32 supplies two descriptor class variables, one that handles 8-bit (ASCII) text and binary data, and one that handles 16-bit (Unicode) text. The actual class 8-bit variables are TPtrC8, TPtr8, TBufC8 <; TInt S> ;, TBuf8 <; TInt S>; and HBufC8, and the 8-bit variables of the abstract class are TDesC8 and TDes8. Similarly, the names of the 16-bit variables are TPtrC16, TPtr16, TBufC16 <; Tlnt S> ;, TBuf16 <; TIntS> ;, HBufC8, TDesC16 and TDes16, respectively.

  This distinction is transparent to descriptors used to represent text. By writing programs that generate and use TPtrC, TPtr, TBufC <; TInt S> ;, TBuf <; TInt S>; and HBufC classes, compatibility for both Unicode and ASCII is maintained. Depending on whether the macro_UNIC0DE is defined, an appropriate variable is selected at the time of configuration. If macro_UNIC0DE is defined, a 16-bit variable is used, otherwise E32. descriptor. As described in the character set, 8-bit variables are used.

  Binary data descriptors must explicitly use 8-bit variables, in other words, the code explicitly uses TPtrC8, TPtr8, TBufC8 <; TInt S> ;, TBuf8 <; TInt S>; and HBufC8 classes Is generated.

  Although it is possible to explicitly use 16-bit variables for binary data, it is not recommended. In general, 8-bit and 16-bit variables are identical in structure and implementation, and the description of the class itself uses names that are independent of configuration throughout.

  Note in particular that many member functions take TUint8 * or TUint16 * type arguments, depending on whether the descriptor is an 8-bit or 16-bit variable. To simplify the explanation, these arguments are replaced with the function prototype TUint? ? Describe as *.

It is a figure which shows the outline of TPtrC. It is a figure which shows the outline of TPtr. It is a figure which shows the outline of TBufC. It is a figure which shows the relationship between TPtr and TBufC. It is a figure which shows the outline of TBufC. It is a figure which shows the outline of HBufC. It is a figure which shows the relationship between TPtr and HBufC. It is a figure which shows the relationship of inheritance and derivation between classes.

Claims (19)

A computer device programmed with an object-oriented operating system configured to handle objects related to text strings, the operating system performing all of the objects, each performing a different function, at least one of which is code And a computer apparatus characterized in that it is treated to belong to one of three classes that have been modified to reduce cycle overhead. A computer peripheral programmed with an object-oriented operating system configured to handle objects related to text strings, wherein the operating system performs all of the objects, each performing a different function, at least one of them. Program to treat one as belonging to one of the three classes, one of which has been modified to reduce code and cycle overhead, and also so that the peripheral treats the object as belonging to the three classes Peripheral device characterized by being made. A computer operating system configured to handle objects related to text strings and encoded in a computer readable medium, wherein the operating system performs all of the objects, each performing a different function, An operating system, characterized in that it is treated as belonging to one of three classes, at least one of which has been modified to reduce code and cycle overhead. A method of operating a microprocessor using a computer operating system configured to handle objects related to text strings, wherein the operating system performs all of the objects, each performing a different function, at least A method characterized in that it is treated as belonging to one of three classes, one of which has been modified to reduce code and cycle overhead. A computer readable medium encoded with a computer operating system configured to handle objects related to text strings, wherein the operating system performs all of the objects, each performing a different function. A medium characterized in that it is treated as belonging to one of three classes, at least one of which has been modified to reduce code and cycle overhead. 6. The apparatus or method according to claim 1, wherein one object of the three classes is a pointer. The apparatus or method of claim 6, wherein the pointer points to the original memory location of the literal text. The apparatus or method according to claim 6, wherein the object has a flat structure. 6. An apparatus or method according to any one of the preceding claims, wherein one object of the three classes handles text of limited length. 10. The apparatus or method of claim 9, wherein the object handling length limited text is provided by a limited subset of memory management functions that may be available. 11. The apparatus or method of claim 10, wherein the object that handles text of limited length uses static memory. 10. The apparatus or method of claim 9, wherein the object that handles text of limited length is a flat structure. 6. An apparatus or method according to any one of the preceding claims, wherein one object of the three classes uses heap memory and requires a full set of available memory management functions. 14. An apparatus or method according to any one of the preceding claims, wherein the object of any of the three classes is polymorphic. Polymorphism is achieved in one instance by an operating system that includes a function that examines a given field in each object and provides different types of action depending on the value in the field. Item 15. The apparatus or method according to Item 14. The apparatus or method of claim 15, wherein the field shares another data item with the machine language. 17. An object according to claim 1, characterized in that it is written in a form that does not change in an 8-bit character set and a 16-bit character set using an alias of a class name that does not change in an 8-bit character set and a 16-bit character set An apparatus or method according to any one of the preceding claims. 18. Apparatus or method according to claim 17, characterized in that it is written in a form that does not change in ASCII and Unicode, using an alias for class names that does not change in ASCII and Unicode. 19. An apparatus or method according to any one of the preceding claims, wherein an object of any of the three classes is essentially specified in length and therefore has no "0" terminator.

Images