1、INTERNATICNAL STANDARD ISO/IEC First edition 1991-12-15 Information technology - Computer graphics - Graphical Kernel System for Three Dimensions (GKS3D) language bindings - Part 4: C Technologies de /information -. lnfographie - Interfaces de langages pour GKS (Graphical Kernel System pour trois di
2、mensions - Partie 4: C Reference number ISO/IEC 8806-4: 1991 (E) scope 1 Normative references . 2 The C Language Binding of GKS3D .3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 conformance . . Functions versus Macros . 3 Character Strings . 3 Function Identifiers . .3 Registration 3 Identifie
3、rs for Graphical Items . 4 Return Values 4 Header Files . . Memory Management . 3.9.1 Functions which Return Simple Lists . 3.9.2 Functions which Return Complex Data Structures 5 Error Handling .6 3.10.1 Application Supplied Error Handlers . 3.10.2 Error Codes 7 3;1 the data record can contain arbit
4、rarily complex implementation-defined data structures. The binding of these two classes of functions is described in detail below. Subclause 3.10 describes the errors that can be invoked during execution of functions which use the memory management policy. 4 GKS3D/C ISO/IEC 8806.4 : 1991(E) The C La
5、nguage Binding of GKS3D Memory Management 3.9.1 Functions which Return Simple Lists Inquiry functions which return a list of items are bound such that the application can inquire about a por- tion of the list. This list is a subset of the implementations internal list and is called the applications
6、list. This allows the application to process the implementations list in a piecewise manner rather than all at once. The application allocates the memory for a list and passes that list to the implementation. The implementa- tion places the results of the inquiry into the list. In order to support t
7、his policy of memory management, three additional parameters have been added to functions which return lists: a) num_elems_appl list: An integer input parameter which is the length of the applications list. The value of nurn zexns appl list indicates the number of items (i.e. list elements) which wi
8、ll fit into the application list. x value-of 0 is valid and allows the application to determine the size of the implementations list (which is returned via num elerns_impl_list) without having the imple- mentation return any of the elements of its i&t. If nuxn_elerns appl_list is negative, GE_APPL_L
9、IST_LENGTH_LT_ZERO is returned as the value of the errorindicator parameter. b) start_ind: An integer input parameter which is an index into the implementations list. (Index 0 is the first element of both the implementations and applications list.) start ind indicates the first item in the implement
10、ations list that is copied into index 0 of the applications list. Items are copied sequentially from the implementations list into the applications list until the applications list is full or there are no more items in the implementations list. If start_ind is out of range, error GE_START_IND_INVAL
11、is returned as the value of the error indicator parameter. c) nuxn_elexns_ixnpl list: An output parameter which is a pointer to an integer. The implementation stores into this parameter the number of items that are in the implementations list. In annex E, a possible underlying mechanism is described
12、. 3.9.2 Functions which Return Complex Data Structures The data returned by the ESCAPE function and the functions which return input device data records or pat- tern tables can be complex in structure. They cannot be represented by a simple list of items. It would be an onerous task for the applicat
13、ion to have to allocate and prepare data structures for these routines. In order to facilitate this task of using these inquiry functions, the binding defines a new resource, called a Store, to manage the memory for these functions. The Store resource is opaque to the application. The application do
14、es not know the structure of the Store or how it is implemented. The Store is defined as a void * . This part of ISO/IEC 8806 defines two new functions which create (in CREATE STORE, bound as gcreate_store) and delete (in DELETE STORE, bound as del_store) a Store. A Store is used by the implementati
15、on to manage the memory needed by the functions which return com- plex data structures. Without specifying an implementation of a Store, it is safe to say that it will contain and control memory needed to hold the data returned by these functions and also contain some bookkeep- ing information about
16、 the contents and size of the memory. The semantics of the Srore resource provide two levels of memory management. The implementation is responsible for managing the memory at a low level because it uses, reuses, allocates and deallocates memory from the system in order to return information to the
17、application. But the application is ultimately responsible for managing the memory at a high level because it creates and deletes Stores. A Store is passed as a parameter to a function returning complex data structures. Another parameter to this function is a pointer to a pointer to a structure whic
18、h defines the format of the returned data. The Store contains memory for the structure and any additional memory referenced by fields within the structure. The application accesses the returned data through its pointer to the structure. It does not use the Store to access the data. A Store continues to hold the information from the function until the Store is deleted by the DELETE STORE function or until the Store is used as an argument to a subsequent function, which returns complex
