Inter-process communication code generation method and system based on header file semantic analysis

Abstract

The application provides a process intercommunication code generation method and system based on header file semantic analysis, which comprises the following steps: obtaining a target C++ header file and dependent header files, parsing API functions, structures, enumerations, type aliases and type dependency relationships, and recursively parsing user-defined types that are not completed, to form a unified semantic model; distinguishing between a composite type to be expanded and a type to be terminated based on the unified semantic model, and constructing a type expansion relationship; generating a dedicated serialization processing function and a dedicated deserialization processing function for the composite type to be expanded, expanding layer by layer along the member relationship, and retaining the real C++ type at the termination expansion member; then generating a unified member call oriented to a serialization overload set and a deserialization overload set, and not determining the specific overload rule of the termination expansion member in the code generation stage; and finally generating a server code, an adapter code, a proxy code, a client code and an API ID mapping code.

Description

Technical Field

[0001] This invention relates to the fields of computer software engineering and inter-process communication code generation technology, and in particular to a method and system for generating inter-process communication code based on header file semantic analysis. Background Technology

[0002] In C++ application software development, different processes need to complete service calls and data transmission via IPC. Current development methods typically involve writing separate server-side code, adapter code, proxy code, client-side code, and parameter serialization and deserialization code based on the API function declarations in the service class. When using code generation tools, they usually first read the function names, parameter types, and return types from the header file, and then the code generator selects the corresponding code template for different C++ types according to its internal type classification rules. For basic types or simple interfaces, the above method can complete the communication code generation. However, when the API function parameters or return types contain nested structures, enumerations, strings, fixed-length arrays, containers, and user-defined types introduced by dependent header files, the code generator needs to continuously identify different levels of type structure and further determine the serialization processing method for each member.

[0003] In complex interface scenarios, the outer type of a composite struct can only represent the composition relationship of its members, while its internal members may belong to primitive types, enumerations, strings, fixed-length character arrays, fixed-length byte arrays, or containers. If the code generator determines the overall processing rules at the level above the composite type, the C++ type differences of the members themselves may be masked. If the code generator continues to establish and maintain independent type classification rules for each member, its internal type judgment results still need to be consistent with the actual type ultimately identified by the C++ compiler. When the nesting level of the struct increases, or type aliases or container elements continue to reference the composite type, this repeated judgment will propagate along the member level. Once the type classification in the generation stage is inconsistent with the actual type in the compilation stage, it may manifest as members entering the wrong serialization processing path, or errors such as unmatched overloading and type incompatibility may not occur until the generated code is compiled.

[0004] Therefore, the technical problem that this invention needs to solve is: when generating inter-process communication code based on C++ header files, how to maintain the complete expansion of the member relationships of the complex structure while avoiding the repeated establishment of complete type determination rules for the terminated expansion members during the code generation stage, and enabling each member to enter the corresponding serialization and deserialization processing path according to its actual C++ type. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by providing a method and system for generating inter-process communication code based on header file semantic analysis, thereby solving the technical problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: The method for generating inter-process communication code based on header file semantic analysis includes the following steps: S1. Obtain the target C++ header file and dependent header files, parse API functions, structures and type dependencies, recursively parse user-defined types that are not fully defined, and form a unified semantic model that records member relationships, member order and real C++ types. S2. Based on the unified semantic model, user-defined structures with members are identified as composite types to be expanded, and basic types, enumerations, strings, fixed-length arrays, and containers are identified as terminating expansion types, thus forming type expansion relationships. S3. Based on the type expansion relationship, generate dedicated serialization and deserialization functions for the composite type to be expanded, generate calls layer by layer along the member relationship, and stop expansion at the member that terminates the expansion, forming a member-level code call relationship that retains the real C++ type. S4. Based on the member-level code call relationship, generate unified member calls for the serialization overload set and the deserialization overload set in the dedicated processing function, without determining the specific overload rules of the terminated expansion member during the code generation stage, thus forming a set of IPC serialization code to be compiled. S5. Based on the unified semantic model, generate server-side code, adapter code, proxy code, client-side code, and APIID mapping code. Combine these with the IPC serialization code set to be compiled to form an inter-process communication code set and compile it. The compiler will then make overload decisions based on the actual C++ types of the terminated expansion members and determine the generated result based on the compilation status, API function name consistency, and file integrity.

[0007] The inter-process communication code generation system based on header file semantic analysis includes: a header file semantic parsing module, a type hierarchy determination module, a composite type code expansion module, a unified member call generation module, and an IPC code generation and compilation verification module.

[0008] The beneficial effects of this invention are as follows: This invention separates the layer-by-layer expansion of composite structures from the specific overload selection of members at the end of the expansion, and retains the actual C++ types of members until the compilation stage for overload resolution. This makes the structural relationships and type handling responsibilities mutually clear, reduces type judgment bias during the generation stage, and improves the consistency and reliability of IPC serialization and deserialization. By using the target C++ header file and dependent header files as a unified source of interface definitions, and performing recursive parsing on user-defined types that are not yet fully defined, API functions, structures, enumerations, type aliases, and dependencies are aggregated into a unified semantic model. This reduces semantic errors caused by inconsistencies in interface descriptions from multiple sources and improves data consistency in subsequent code generation.

[0009] This invention distinguishes between composite types to be expanded and types to be expanded, based on a unified semantic model, and forms type expansion relationships along member references. This ensures that nested structures continue to expand only where needed, while maintaining the true C++ types of members to be expanded. This reduces invalid type splitting and incorrect classification, and improves the stability of complex interface type hierarchical processing. By establishing dedicated serialization and deserialization functions for composite types to be expanded, and forming member-level call relationships layer by layer according to member order, the member paths of nested structures remain continuous and verifiable, reducing member omissions, call relationship conflicts, and order deviations, thus improving the completeness and consistency of composite type code generation.

[0010] This invention generates unified member calls for serialization and deserialization overload sets by terminating the expansion of members, and retains the actual C++ types until the compilation stage. This eliminates the need for the code generator to repeatedly maintain complete leaf type determination rules, reducing matching errors caused by inconsistencies between the generation rules and compiler type recognition, and improving the reliability of type processing. By generating server, adapter, proxy, client, and API ID mapping code based on a unified semantic model, and performing compilation, API function name consistency checks, and file integrity checks on the resulting inter-process communication code set, the interface generation results are subject to unified verification, reducing the generation failure rate caused by unmatched overloads, missing files, and interface inconsistencies. Attached Figure Description

[0011] Figure 1 This is a flowchart of the inter-process communication code generation method based on header file semantic analysis of the present invention; Figure 2 This is a framework diagram of the inter-process communication code generation system based on header file semantic analysis according to the present invention. Detailed Implementation

[0012] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0013] Example 1: As Figure 1 As shown, this embodiment provides a method for generating inter-process communication code based on header file semantic analysis, including the following steps: S1. Obtain the target C++ header file and dependent header files, parse API functions, structures and type dependencies, recursively parse user-defined types that are not fully defined, and form a unified semantic model that records member relationships, member order and real C++ types. S2. Based on the unified semantic model, user-defined structures with members are identified as composite types to be expanded, and basic types, enumerations, strings, fixed-length arrays, and containers are identified as terminating expansion types, thus forming type expansion relationships. S3. Based on the type expansion relationship, generate dedicated serialization and deserialization functions for the composite type to be expanded, generate calls layer by layer along the member relationship, and stop expansion at the member that terminates the expansion, forming a member-level code call relationship that retains the real C++ type. S4. Based on the member-level code call relationship, generate unified member calls for the serialization overload set and the deserialization overload set in the dedicated processing function, without determining the specific overload rules for the terminated expansion member during the code generation stage, thus forming a set of IPC serialization code to be compiled. S5. Based on the unified semantic model, generate server-side code, adapter code, proxy code, client-side code, and APIID mapping code. Combine these with the IPC serialization code set to be compiled to form an inter-process communication code set and compile it. The compiler will then make overload decisions based on the actual C++ types of the terminated expansion members and determine the generated result based on the compilation status, API function name consistency, and file integrity.

[0014] S1 specifically includes the following sub-steps: S110. Obtain the C++ header file and its dependent header files that serve as the interface definition source, and establish the header file input set for this semantic parsing. Specifically, when the application software development project starts the IPC code generation task, the target C++ header file specified by the developer is read through the file input interface of the code generator. The target C++ header file serves as the sole interface definition source for the IPC interface between the current server and the client. File reading occurs at the beginning of each code generation task, without periodic sampling. The input content consists of C++ source code text and file path information, without involving physical quantities and units of measurement, and without performing numerical denoising, calibration, or normalization processing.

[0015] Application software development refers to the development process of building applications and their inter-process interfaces using C++ source files, header files, and compilation tools; visual programming refers to the programming method in which developers establish service interfaces through graphical interface editing tools and convert and save the interfaces as C++ header files that meet the input requirements of this method; the reinforcement learning function module refers to the software function module in the application software that performs policy learning or policy update functions and exchanges input parameters or output results with other processes through API functions declared in the target C++ header file. The training, reward calculation, and policy update processes inside the reinforcement learning function module do not participate in the header file semantic parsing and IPC code generation of this method.

[0016] Therefore, the interfaces formed by manual coding, visual programming, and reinforcement learning functional modules all use the final C++ header file as the same data entry point, without establishing a second interface description source. The `include` directives in the target C++ header file are read, and dependent header files are retrieved along the `include` reference relationships that can be resolved from the current application software development project file path, until no dependent header files remain to be retrieved, forming a header file input set. ; Where H represents the header file input set, which has no unit; This indicates the target C++ header file specified for this code generation task, without units; D indicates the dependency header file retrieval operation, used to recursively retrieve dependency header files that can be located by the current project path along the include reference relationship; Indicates the target C++ header file The set of all dependent header files obtained as the starting point, without units; This represents the union of sets, with curly braces indicating the set comprised of its elements. All files and references are derived from the file system of the current application software development project.

[0017] If the file corresponding to the include directive cannot be located or read, a dependency missing state or a read failure state will be formed respectively, and the formation of the current unified semantic model will be terminated. If the file at the same path has already been added to H, it will be marked as processed and will not be added again, thus avoiding the duplicate reading of dependency files. S110 finally outputs the header file input set and the interface definition source identifier of the target C++ header file, which will be used by S120 to extract service interface semantics and type declaration semantics within the unified file scope.

[0018] S120. Extract service interface semantics and type declaration semantics based on the header file input set to form an initial semantic information set. Specifically, taking the header file input set output in S110 as input, first identify service class declarations in target C++ header files with interface definition source identifiers, obtain the service class names used for IPC code generation according to the naming format of Service, Server, _Service, and _Server classes, and record the namespace nesting relationship of the service classes; then, read member variables and member C++ types in the original declaration order within the scope of the service class declaration, and check whether there are user-defined constructors.

[0019] Further, read the API function declarations in the service class item by item, and record the function name, return type, number of parameters, parameter order, parameter name and corresponding C++ type for each API function, and record the identifiable notification function attributes in the header file.

[0020] For interfaces formed through visual programming during application software development and interfaces exposed by service classes for reinforcement learning function modules, the function and type semantics are extracted only based on the final C++ function declaration. The API is not reinterpreted based on the graphical node name, reinforcement learning strategy name, or business function name, so that the C++ interface semantics on which the IPC code is based will not be changed by different software function sources.

[0021] After extracting the API functions, the system parses the struct, typedef struct, enum, enumclass, and type alias declarations in the header file input set. For structs, it records the struct name, ordered member list, member name, member C++ type, and element type and array length of fixed-length arrays. For enumerations, it records the enumeration name and enumeration value definition. For type aliases, it records the correspondence between the alias name and the type it points to.

[0022] If an API parameter lacks a complete type, a struct member lacks a type declaration, or the scope of a class or struct declaration cannot form a complete syntactic scope, the corresponding object will be in a state of incomplete semantic information and will not be marked as having completed parsing. S120 ultimately forms an initial semantic information set, which includes service class semantic information, API function semantic information, struct semantic information, enumeration semantic information, type alias relationships, namespace information, and header file dependency information, while maintaining the order of API parameters and struct members consistent with the declaration order in the target C++ header file; the initial semantic information set is input to S130 to determine dependency types that have not yet been fully defined and to perform recursive parsing.

[0023] S130: Perform recursive parsing on the incomplete dependency types in the initial semantic information set, and organize the parsing results into a unified semantic model. Specifically, taking the initial semantic information set formed in S120 as input, start by checking the completeness of the type definition of each API function's parameter type and return type, and continue to check the structure members, type alias target type, and container element type.

[0024] When the type can be determined to be a primitive type, string, enumeration, or fixed-length array, record its exact C++ type without continuing to search for member definitions; when the container element type or struct member type belongs to a user-defined type that has not yet been fully defined, add the corresponding user-defined type to the initial set of types to be resolved. .in, This represents the initial set of types to be parsed before the start of the 0th round of recursive parsing. It has no unit and its members come from API parameter types, return types, and user-defined types referenced by parsed struct members, type aliases, or container elements but which have not yet been fully defined.

[0025] The recursive resolution relation is updated according to the following formula: ; Where k represents the recursive parsing cycle number, which is a non-negative integer starting from 0 and incrementing, with no unit; The set of types that have entered the recursive resolution relation up to the kth round has no unit; p represents the C++ type currently being resolved in the kth round has no unit; q represents the next level of C++ type obtained by referencing a struct member, type alias, or container element of type p has no unit. This indicates that the definition of type p contains a type reference to type q; To represent the union of sets, Indicates belonging to, A vertical bar indicates that an element does not belong to the set, and a vertical bar indicates that the element in the set must satisfy the condition that follows it.

[0026] The type names and reference relationships mentioned above are all derived from the C++ declarations parsed in S120, and do not involve numerical units or out-of-bounds values. In the recursive formula... This represents the cumulative set of user-defined types included in the recursive parsing up to the kth round. Types remain in this set after parsing is completed, and duplicate parsing is avoided by marking them as parsed. The newly added q in the recursive formula is limited to user-defined types that require a complete definition. Basic types and types that do not require finding the definition of user-defined types are not added as new parsing objects.

[0027] For each new user-defined type definition obtained, its structure member names, member order, and member C++ types are written into the initial semantic information set, and the types referenced by the new members are checked. Recursive parsing ends and a unified semantic model is formed only when no more new user-defined types are found and all required types have been fully defined. If, after searching the header file input set, there are still required types whose complete definitions cannot be obtained, an incomplete type definition state is formed, and the output of the unified semantic model stops.

[0028] For mutual references between types, declarations with the same name, or repeated definitions, the type is located based on the namespace, scope, and declaration correspondence. Types with the same name in different namespaces or scopes are recorded separately, and the same type declaration is not resolved repeatedly when accessed repeatedly. For type alias chains and forward declarations, the search continues to find their final type definition, and an error is not directly judged because the name appears again. If there are incompatible definitions of the same type, or if there are circular references to type aliases that prevent the determination of the final type, a resolution error state is generated and the output of the unified semantic model is stopped. S130 ultimately organizes the service class name, namespace, API function, parameter order, parameter C++ type, return type, structure member relationship, member order, enumeration, type alias, and resolved type dependency relationship into a unified semantic model; the unified semantic model is the only output of S1 and is directly provided to S210.

[0029] S2 specifically includes the following sub-steps: S210: Based on the unified semantic model output by S130, establish an API type entry set and form a unified type description record for C++ types participating in type hierarchy judgment. Specifically, establish type judgment entry points from the parameter type and return type of each API function; when the parameter type or return type is directly a user-defined structure, use the corresponding structure as the type judgment object; when the parameter type or return type is a container, use the container type itself as the current type judgment object, while preserving the reference relationship between the container element type and the corresponding type definition in the unified semantic model.

[0030] For type aliases, the final C++ type they point to is located based on the type alias relationship already formed in S130, while the correspondence between the alias name and the final type is preserved, so that subsequent type hierarchy judgments are based on the actual C++ type structure rather than just the name string.

[0031] The type description record stores the type representation in the original declaration and the object type used for structure hierarchy determination. For read-only lvalue references used as input parameters, it is determined whether the referenced object is a struct, container, or other supported type based on its non-const type, while retaining the template argument, array element type, and array length. This determination is only used to determine the structure hierarchy, does not change the original interface declaration, and does not remove the const property of the object through type casting during call generation.

[0032] During deserialization, parameter values ​​are first restored to writable local objects of the corresponding object type, and then the object is passed in the read-only reference form of the original API declaration. The type representation used to form the API ID is still normalized according to the original function declaration, and the object type obtained during structure judgment does not directly replace the reference and qualification information in the original signature. For pointer types, pointer dereference expansion is not performed by default, and pointer addresses are not transmitted; for pointer, reference, or qualification types that do not explicitly provide value passing and restoration rules, they are handled according to the unsupported type branch of S220.

[0033] For each type-determined object, a type description record is formed. The type description record includes at least the type name, type definition source, whether it is a user-defined structure, number of members, ordered member list, member C++ type, whether it belongs to a basic type, whether it belongs to an enumeration, whether it belongs to a string, whether it belongs to a fixed-length array, the element type of the fixed-length array, whether it belongs to a container and the type of the container element.

[0034] For API functions used by manual coding, visual programming, and reinforcement learning modules, as long as they ultimately fall into a unified semantic model, that is, use the same fields to establish type description records, different application software development methods will not form independent IPC type classification chains.

[0035] If a user-defined type is not fully defined in the unified semantic model or if a parsing error has occurred in S130, the type will not proceed to S220, and the incomplete type definition state will be output. For types that have already completed recursive parsing, S210 will not restart the recursive parsing. S210 ultimately outputs the API type entry set and the corresponding type description record, which will be used by S220 to determine the composite type to be expanded and the type to be terminated.

[0036] S220: Based on the API type entry set and type description record, determine the composite type to be expanded and the type to be expanded, and retain the actual C++ type of each member. Specifically, sequentially read the type judgment object formed in S210, and for the current C++ type x, read its type category and the set of expandable structure members. Where x represents the C++ type currently being evaluated in type hierarchy checks, and has no unit; Represents the set of expandable struct members of type x in the unified semantic model, without units.

[0037] For types that have been identified as user-defined structs and have more than one member, the struct expansion determination result is formed according to the following formula: ; in, This represents the result of the structure expansion judgment for the current C++ type, without units; This indicates that the current type is a composite type to be expanded; This indicates that the current type is the type that terminates expansion; Represents an empty set; =Indicates not equal to; L indicates the termination of the expanded type category collection, which has no unit and consists of primitive types, enumerations, strings, fixed-length arrays and container types; It indicates that it belongs to.

[0038] Both the type and category are derived from the unified semantic model formed by S130, without using training samples, empirical thresholds, or numerical parameters. When x is a user-defined structure and If x is not empty, it is determined as a composite type to be expanded; if x belongs to set L, it is determined as a type to be terminated.

[0039] For user-defined structs with zero members, they are not directly categorized as terminated expansion types based on the empty member set. If the current binary serialization tool does not have a callable dedicated processing function corresponding to this empty struct type, a "type not supported" state is created, and the type stops proceeding to S230. Similarly, user-defined structs with missing member definitions are also classified as having an incomplete type definition, and are not treated as empty structs. Termination of expansion only indicates that the code generation stage will no longer further split the struct members; it does not mean that the specific serialization rules have been determined.

[0040] In the above judgment formula This only records the user-defined struct members that this method needs to expand, excluding internal implementation members of types such as strings and containers; L specifically represents the collection of various C++ types belonging to the aforementioned termination expansion category, therefore, This indicates that the current specific type belongs to this set.

[0041] For user-defined structures with zero members, if the binary serialization tool has provided both dedicated serialization and deserialization functions corresponding to its type, it is added to L as a special termination expansion type with existing functions, and the calling relationship between the two types of functions is recorded. The existing functions are called directly in the future, and S310 is not generated again. If the corresponding function in either direction is missing, a type-unsupported state is formed.

[0042] For other data types that neither meet the conditions for the composite type to be expanded nor belong to the set of terminating expansion types, a "type not supported" state is also created, and no further processing code for that type is generated. When the API return type is void, it is only recorded as having no return value, and void is not considered a data type that needs to be serialized. S220 finally outputs the set of composite types to be expanded, the set of terminating expansion types, and the actual C++ types retained for each member, for S230 to construct the type expansion relationship.

[0043] S230. Construct type expansion relationships based on the set of composite types to be expanded, the set of terminating expansion types, and member reference relationships in the unified semantic model. Specifically, establish the type expansion starting point from the parameter type and return type of each API function; when the starting point belongs to the composite type to be expanded, connect it to its direct members according to the member order recorded in the unified semantic model.

[0044] When a direct member still belongs to a composite type to be expanded, the connection continues to the next level member of the corresponding structure. When a direct member belongs to a terminated expansion type, the structural hierarchy expansion stops at that member, while preserving its actual C++ type and the member positions within its respective structure. The layer-by-layer processing in S230 uses the recursive resolution result already completed in S130, without re-searching for unresolved type definitions. Therefore, the recursive resolution in S130 is used to obtain type definitions, while S230 is used to organize the already defined composite structures into the hierarchical relationships required for subsequent code generation. The two processes have different objects and technical functions.

[0045] When a composite type to be expanded is referenced by multiple API functions or multiple upper-level structures, only one type definition is retained. Simultaneously, the reference paths from different entry points to the members of that type are recorded to avoid duplicate references that alter the member order. For illegal mutual references, type conflicts with the same name, or duplicate definitions already formed in S130, the type expansion path is not reconstructed. The manual coding interface, visual programming interface, and reinforcement learning function module interface all form the same type expansion relationship according to the final C++ type relationship, ensuring that different application software development sources do not change the structural hierarchy of the composite structure as it expands layer by layer towards the leaf members.

[0046] When API parameters, return values, or struct members are container types, the structural hierarchy expansion stops at the container location, meaning the container's own internal implementation members are not expanded. Simultaneously, following the container element type reference relationships recorded in the unified semantic model, it is checked whether the element type requires a dedicated processing function. If the element type is a composite type to be expanded, the element type and its member expansion relationships determined according to rule S220 are included in the type expansion relationship output in this step, serving as the dedicated processing function generation object for S310. This same processing is performed even if the composite type only appears as a container element.

[0047] If the element type is still a container, its element type is checked again; the same user-defined type is only registered once, and the existing record is reused when referenced again. The above element type reference relationship is used to collect the types that need to generate processing functions, without changing the container itself as the determination of the termination expansion type. The actual reading and writing of each element in the container is still completed by the container overload in S420 calling each item one by one. S230 finally outputs the type expansion relationship, which includes the API type entry, the composite type to be expanded, the reference order of each layer of members, the termination expansion position, and the real C++ type of the termination expansion member, and serves as the direct input of S310.

[0048] S3 specifically includes the following sub-steps: S310: Read the type expansion relationship output by S230 and establish a one-to-one correspondence between the composite type to be expanded and the dedicated serialization processing function and the dedicated deserialization processing function to be generated.

[0049] A dedicated serialization processing function refers to a C++ function overload that is ultimately generated in the IPC serialization source code for a composite type to be expanded. Its function body calls the serialization processing of each member in the order of the corresponding structure members. A dedicated deserialization processing function refers to a C++ function overload that is ultimately generated in the IPC deserialization source code for the same composite type to be expanded. Its function body is used to restore the structure members according to the corresponding member relationships.

[0050] The data object used internally by the code generator to describe these C++ functions to be generated is called a dedicated processing function generation record. This dedicated processing function generation record is not the same object as the final generated C++ function. Specifically, the BinarySerializerGenerator sequentially reads the composite types to be expanded, the member reference order, and the termination position in the type expansion relationship, and obtains the structure name, ordered member list, and the actual C++ types of the members from the unified semantic model. For each composite type to be expanded, a dedicated serialization processing function generation record and a dedicated deserialization processing function generation record are established.

[0051] If the same composite type to be expanded is referenced by multiple API parameters, return values, or upper-level structures, only one set of corresponding generation records is created, and structure processing functions are not repeatedly generated due to increased reference counts. If the composite type to be expanded lacks member definitions, the member order cannot be determined, or there is no complete structural path leading to the terminated expansion type in S230, an incomplete structure expansion state is formed, and S320 is not entered. S310 finally outputs a composite type-specific processing function mapping, which includes the composite type to be expanded, two types of specific processing function generation records, and a corresponding ordered member list, for S320 to generate actual member-level processing statements.

[0052] S320: Generate member-level serialization and deserialization statements based on the composite type-specific processing function mapping and type expansion relationship, and pass the structure expansion process layer by layer along the member relationship of the composite type to be expanded. Specifically, for each composite type to be expanded, read the current member sequentially according to its ordered member list, and query the type expansion relationship in S230 to determine whether the current member belongs to the composite type to be expanded or the terminated expansion type.

[0053] When the current member belongs to the composite type to be expanded, a call to the corresponding serialization processing function of the member is formed in the current serialization processing function to be generated, and a call to the corresponding deserialization processing function is formed in the current deserialization processing function to be generated, so that the code call relationship enters the next level structure; the next level composite type to be expanded continues to perform the same processing according to its own member order until the terminating expansion type is reached.

[0054] When the current member belongs to the terminated expansion type, S320 does not know its final corresponding primitive type, enumeration, string, fixed-length array or container overload, but only forms the position for the member to be bound and associates the real C++ type reserved by S230 with the position.

[0055] For nested interfaces formed by visual programming and structured parameters passed to reinforcement learning functional modules via API, the layer-by-layer expansion is based solely on the final C++ structure member relationships. Graphical node relationships and reinforcement learning internal policy states are not included in the IPC code generation chain, ensuring that differences in business implementation during application software development do not disrupt the consistent processing of the C++ type hierarchy. If a member is simultaneously marked as both a composite type to be expanded and a type to be terminated, a type hierarchy conflict occurs, and code generation for the current composite type is stopped. S320 ultimately outputs the layer-by-layer member processing chain, recording the composite type to be expanded, the member order, the next-level dedicated processing function for each composite member, and the actual C++ type of the terminated member, for S330 to perform an integrity check.

[0056] S330: Perform integrity checks on the layer-by-layer member processing chain and form member-level code call relationships. Specifically, take each API parameter type, return type, or its referenced composite type as the entry point for the check, and check each member path along the layer-by-layer member processing chain formed in S320; for the composite type to be expanded, check whether it has both a dedicated serialization processing function generation record and a dedicated deserialization processing function generation record, and check whether each member in the ordered member list has a unique subsequent state, that is, connecting to the next layer of composite type to be expanded or terminating in a terminating expansion type.

[0057] For members connecting to the next level of the composite type to be expanded, continue checking the members at the next level; for members terminating the expansion, check whether the member position and the actual C++ type are saved simultaneously. The actual C++ type of the member terminating the expansion must not be converted to a numeric category or encoding number defined internally by the code generator in S330, to ensure that subsequent code still carries the primitive type semantics that can be recognized by the C++ compiler.

[0058] If a member lacks a subsequent state, a member corresponds to multiple mutually exclusive states, or the structural path cannot reach the terminating expansion type, an incomplete member-level call relationship is formed, and the corresponding path is not output to S410. After inspection, the dedicated processing function generation record, member order, next-level call relationship of composite members, actual C++ type of terminating expansion member, and member position are organized together into a member-level code call relationship. S330 finally outputs the member-level code call relationship and uses it as direct input to S410, thereby completing the continuous interface connection between S230 and S310 and between S330 and S410.

[0059] S4 specifically includes the following sub-steps: S410: Using the member-level code call relationship output by S330 as input, extract the terminating expanded member and establish a set of member call records to be bound. Specifically, sequentially read the dedicated processing function generation record, member order, next-level call relationship of composite members, actual C++ type and member position of the terminating expanded member in the member-level code call relationship; for each terminating expanded member, check whether the composite type to be expanded, member name, member order and actual C++ type are complete.

[0060] When all elements are complete, the terminated expanded member is created as a member call record to be bound. This record includes at least the associated dedicated handler function, the member object access location, the actual C++ type, the serialization call direction, and the deserialization call direction. "To be bound" indicates that the code generator already knows the member's actual C++ type, but has not yet mapped the member to a specific serialization or deserialization overload during the code generation phase.

[0061] For manual coding interfaces, visual programming interfaces, and reinforcement learning function module interfaces, as long as the same member-level code call relationship is formed, the same binding process is adopted, ensuring that the application software development source does not change the subsequent type decision method for terminating member expansion. If a member lacks a real C++ type, the member position does not correspond to its own structure, or the same member has mutually exclusive functions, then an incomplete binding record state is formed, and the member is stopped from entering S420. S410 finally outputs the set of member call records to be bound.

[0062] S420. Generate unified member serialization calls and unified member deserialization calls based on the set of member call records to be bound, and accept the actual C++ type of the terminated expanded member through an explicit overload set. Specifically, the preset serialization overload set and preset deserialization overload set are set in the binary serialization tool code, including C++ function or template overloads set at least for basic types, enumerations, std::string, fixed-length character arrays, fixed-length byte arrays, and std::vector types.

[0063] For basic types, the corresponding POD processing channel is used; for enumerations, the POD processing channel matching the actual C++ type of the enumeration is used; for std::string, the length information corresponds to the string content; for char[N] type fixed-length character arrays, the effective character length not exceeding the array length N is obtained through independent array overload matching the char element type, and the effective character content is processed; for unsigned char[N] type fixed-length byte arrays, they are processed as fixed-byte arrays through independent array overload matching the unsigned char element type. Here, N represents the number of elements in the fixed-length array in the C++ declaration, is a positive integer, has no unit, and originates from the array declaration parsed from S120.

[0064] For std::vector <t>T represents the template element type of std::vector, which has no unit and is derived from the C++ type of container elements stored in the unified semantic model. The serialization overload first processes the 4-byte length prefix, and then calls the same serialization function on each T type element in the order of container elements.

[0065] When T is a composite type for which S310 has already generated a dedicated serialization function, the compiler determines which composite type's dedicated serialization function to use. When T is a basic type, enumeration, string, fixed-length array, or other terminating expansion type with matching overloads, the overload matching T's actual C++ type is used. The deserialization overload reads length information and member contents according to the same type correspondence, ensuring that serialization and deserialization use the corresponding processing paths.

[0066] For each member call record to be bound in S410, the code generator only generates unified serialization and deserialization calls for the member object in the dedicated processing function of the corresponding composite type, without copying new leaf type-specific overloads. The actual C++ argument types in the generated code participate in the overload resolution during S520 compilation.

[0067] If the unified semantic model has already recorded the dependent header files required to terminate the expansion of members, but the current binary serialization generated file has not yet written the corresponding include reference, then the reference is supplemented according to the header file dependency information in the unified semantic model; if the corresponding type definition has formed a dependency missing or resolution failure state in stage S110 or S130, then the type must not enter S420, so there is no situation where code is generated with missing source header files.

[0068] The unified member serialization call takes the output byte buffer and the member object to be written as input, while the unified member deserialization call takes the input byte buffer, the current read position, and the member object to be restored as input. The member object access position represents the expression for accessing the corresponding member from the current structure object, generated according to the member name saved in the unified semantic model. Fixed-length arrays are passed to the corresponding overloads via array references to preserve the element type and array length, and are written to the original member array during deserialization. The declarations of each preset overload and composite type-specific processing function are placed before the function definition that calls them, and enable the container template definition to find the declaration of the specific processing function corresponding to the composite element type.

[0069] In this embodiment, the POD processing channel is only used for basic arithmetic types and enumerations. The number of bytes is determined according to the sizeof result of the corresponding type, and the object representation is copied to the output buffer using memcpy. During deserialization, the same number of bytes are copied to an existing object of the same type. This processing method is suitable for runtime environments where both ends of the communication have the same byte order, corresponding type width, and object representation. It does not directly copy pointer addresses, strings, or the internal storage structure of container objects as communication content.

[0070] In this embodiment, the length prefix is ​​uniformly a 4-byte unsigned integer, and it is written and read in the order of least byte first. The length prefix of std::string records the number of bytes of the string content, and then the corresponding byte content is written. The receiving end restores the string according to this length. The effective character length of char[N] is determined by strnlen within a maximum of N elements. The length prefix records the effective character length, and then only the corresponding number of characters are written, without writing a separate terminator. The receiving end first reads the length. If the length exceeds N, it is determined that the read has failed. If the length does not exceed N, the corresponding character is read and written to the array. When the length is less than N, the remaining array elements are set to zero. When the length is equal to N, all N characters are restored, and no terminator is written outside the array boundary. At this time, the array does not have the guarantee of a zero-terminated string. unsigned char[N] is written and read in fixed N bytes, and no length prefix is ​​set separately.

[0071] In this embodiment, `char[N]` is used for character content transmitted according to the effective character length, and `unsigned char[N]` is used for fixed-length binary content that needs to retain all N bytes byte by byte. This distinction belongs to the interface data convention supported by this embodiment. For interfaces that use `char[N]` to carry arbitrary binary content or require the retention of all bytes after the first zero character, the above character array overloading rule does not apply. For `char[N]` arrays that are not terminated with zero after recovery, subsequent accesses are bounded by the effective character length or the array length N, and they are not directly passed to string processing functions that require zero termination.

[0072] std::vector <t>The 4-byte prefix records the number of container elements, but does not record the total number of bytes of all elements; during serialization, the corresponding processing function is called item by item in the order of the elements, and during deserialization, the elements are restored item by item in the same number and order.

[0073] Write failure is determined when the length to be written exceeds the range of a 4-byte unsigned integer. Before reading the length field and its contents, the remaining input bytes are checked to ensure they are sufficient. If insufficient bytes are read or the target object cannot be recovered, failure is returned, and the read result is not considered a valid recovery result. The final output of S420 contains the uncompiled member handling code, including unified member calls, actual C++ types, and required header file references.

[0074] S430: Write the code to be compiled into the corresponding dedicated serialization and deserialization functions, forming a set of IPC serialization code to be compiled. Specifically, using the composite type dedicated processing function mapping established in S310, the member-level code call relationship output in S330, and the code to be compiled output in S420 as input, according to the member order of each composite type to be expanded, write the calls of the composite members to the next-level dedicated processing function and the unified member calls corresponding to the terminating expanded member into the function body of the same dedicated processing function, so that each type expansion path from the outer composite structure to the terminating expanded member corresponds to a continuous C++ call path.

[0075] For dedicated serialization processing functions, the member processing order is consistent with the structure declaration order in the unified semantic model; for dedicated deserialization processing functions, the same member order and member level are used to restore member values. After writing is complete, it checks whether each composite type to be expanded simultaneously forms two types of dedicated processing functions, whether each member has a unique processing statement, whether composite members are connected to the corresponding next-level dedicated processing function, whether the terminating expanded member retains its true C++ type, and whether the member processing order is consistent with the unified semantic model.

[0076] If any check item is missing, the generation is incomplete, and the corresponding code is not included in the set of IPC serialization code to be compiled. For composite types that pass the checks, the dedicated serialization processing function, dedicated deserialization processing function, unified member calls, and required header file references are written into the binary serialization generation file. S430 finally outputs the set of IPC serialization code to be compiled, which is then used as the direct input to S510.

[0077] S5 specifically includes the following sub-steps: S510 takes the set of IPC serialization code to be compiled output by S430 and the unified semantic model formed by S130 as input, forms an API ID mapping relationship and generates server code, adapter code, proxy code, client code and APIID mapping code, and then forms a set of inter-process communication code.

[0078] Specifically, when establishing a common generation context for all code generators, the ApiIdGenerator reads the function name, parameter type sequence arranged in the order of header file declaration, and return type of each API function. It uses only the function name, parameter type sequence, and return type as API identity input to form the corresponding API ID mapping relationship, without using the position of the API function in the function list as input for API ID calculation. Therefore, the same function name, the same parameter type sequence, and the same return type in the same header file will obtain the same API ID when generating duplicate code. Adding or deleting other APIs or adjusting the order of APIs will not change the API ID of existing APIs.

[0079] As a specific implementation of the aforementioned API ID mapping relationship, this embodiment uses the standardized function signature string itself as the API ID, without truncating it or converting it into a function sequence number. When forming this string, the type alias is resolved to the final pointed-to type. For user-defined types, a qualified name containing the namespace and scope is used, and fixed type writing and separation rules are adopted. The complete string is formed in the order of function name, left parenthesis, comma-separated ordered sequence of parameter types, right parenthesis, arrow separator, and return type. Parameter names and default arguments are not written into the string. The same type within the same semantic model always uses the same representation.

[0080] API ID mappings are established separately for each service class, which is distinguished by a qualified class name containing the namespace. The adapter first determines the service to which the request belongs, and then matches the target function in the mapping of that service based on the complete API ID, without mixing mappings from different services. When the same API declaration is read repeatedly, the records are merged. If different APIs within the same service generate the same API ID due to differences in declarations not included in the identity input, an identifier conflict status is output and generation is stopped, without changing the existing identifiers of other APIs by renumbering.

[0081] Subsequently, ServerGenerator reads the service class and API function information from the unified semantic model to generate the server-side business call framework; AdaptorGenerator reads the same API function information and the already formed API ID mapping relationship to generate connection management and message routing code; ProxyGenerator generates client proxy code; ClientGenerator generates application software call entry code; and ApiIdGenerator writes the aforementioned mapping relationship into the APIID mapping file.

[0082] All generators share the same unified semantic model and API ID mapping, and do not extract function signatures or routing identifiers from other generated files. The actual writing order of each generated file does not require the content of the previous generated file to be used as the data input for the next generated file; their consistency comes from the common semantic input.

[0083] For the C++ interfaces formed by visual programming and the C++ interfaces exposed by the reinforcement learning functional modules, the API ID and communication code of each layer are also formed according to the final function name, parameter type and return type. The visual node number or the internal state of reinforcement learning is not used as the routing identifier.

[0084] Finally, the set of IPC serialization code to be compiled, along with the server-side code, adapter code, proxy code, client-side code, and API ID mapping code, are combined to form the inter-process communication code set. If any expected generated component is missing, a missing generated file state is created, and the S520 complete compilation process is not entered. The S510 ultimately outputs the inter-process communication code set.

[0085] S520: Compile the inter-process communication code set, enabling each termination expansion member to complete the compile-time resolution of serialization overload and deserialization overload based on the actual C++ types, and output the compilation status and compilation error information. Specifically, call g++ to compile the source files that need to be compiled in the inter-process communication code set. The compilation input includes the corresponding generated source files, generated header files, target C++ header files, and dependent header files recorded by the unified semantic model and written into the generated files.

[0086] When the compiler processes the composite type-specific handling function formed by S430, it uniformly calls the actual C++ type of each terminating expansion member, and selects a matching handling function from the preset serialization overload set or preset deserialization overload set exposed by S420 according to the C++ function and template overload resolution mechanism; when the current member is a nested composite type or std::vector <t>When T is a composite type, the compiler can match the corresponding composite type-specific processing function generated by S310 based on the actual C++ type of T; when the current member is another terminating expansion type, it matches the corresponding basic type, enumeration, string, array or container overload.

[0087] When a valid match exists, the compilation process continues; when no matching overload exists, type incompatibility occurs, or necessary declarations are missing, g++ generates the corresponding compilation error and returns a failure status. The code generation system only receives the compilation success or failure status of each generated source file, as well as the compiler error text and error code line when compilation fails. It does not output the overload decision completed internally by the compiler as an independent data object, nor does it automatically select another serialization rule based on compilation errors, nor does it re-execute S130 recursive parsing, nor does it modify the S220 type hierarchy judgment.

[0088] Therefore, S130 is responsible for restoring the actual type definition, S230 to S330 are responsible for expanding the compound structure, S410 to S430 are responsible for preserving the actual C++ types and forming a unified call, and only in S520 does the C++ compiler implement the specific leaf type overload decision. S520 finally outputs the compilation status of each generated source file and the compilation error information when compilation fails, and serves as the verification input for S530.

[0089] S530, based on the compilation status and compilation error information output by S520, performs API consistency checks and file integrity checks on the inter-process communication code set, and forms the final generated status. Specifically, it first checks whether each source file that needs to be compiled in S520 has obtained a compilation result; if any source file fails to compile, the file name, compilation error information, and error code line are recorded as the compilation verification failure result.

[0090] Then, an API consistency check is performed. Using the API function names in the S130 unified semantic model as a benchmark, it checks whether the corresponding function names exist and remain consistent in the generated server-side code, adapter code, proxy code, and client code. S520 checks the compilability of each generated source file; this step checks the existence and consistency of the corresponding function names. If all verification items pass, it means the generated code has passed the compilation, function name, and file integrity checks set by this method. However, it does not conclude that parameter position mapping, cross-file function signatures, final linking, and interface runtime semantics have all passed verification.

[0091] Then, based on the expected file list corresponding to the inter-process communication code set established by S510, file integrity checks are performed on the server code, adapter code, proxy code, client code, binary serialization code, and API ID mapping code; if an expected file does not exist, a file integrity verification failure result is generated.

[0092] If any of the compilation verification, API consistency check, or file integrity check fails, the IPC code generation task for this application software development project will be marked as failed, a corresponding error report will be output, and a non-zero exit status will be returned. The target C++ header file will not be automatically modified, recursive parsing will not be restarted, the interface structure generated by visual programming will not be changed, and the C++ interface exposed by the reinforcement learning function module will not be changed. Only when all verification items pass will the inter-process communication code set be marked as the verified generated code, which can be used for subsequent application software compilation, linking, and inter-process communication calls.

[0093] This forms a continuous technical loop from reading the target C++ header file, recursive parsing, layer-by-layer expansion of composite types, terminating the preservation of the actual C++ types of expanded members, compile-time overload resolution, to complete IPC code verification.

[0094] Example 2: Figure 2 As shown, this embodiment provides an inter-process communication code generation system based on header file semantic analysis, including: The header file semantic parsing module is used to obtain the target C++ header file that serves as the source of the interface definition and the dependent header files obtained along the include reference relationship. It parses service classes, API functions, parameter types, return types, structures, enumerations, type aliases and type dependencies. It also recursively parses the parameter types and return types of API functions, as well as user-defined types referenced by structure members, type aliases and container elements that have not yet been fully defined, forming a unified semantic model that records the structure member relationships, member order and the actual C++ types of the members. The unified semantic model is then output to the type hierarchy determination module. The type hierarchy determination module receives the unified semantic model, establishes API type entries from the parameter types and return types of API functions, and determines user-defined structures with members as the composite types to be expanded based on the type category and structure member information of each entry type. It determines basic types, enumerations, strings, fixed-length arrays, and containers as the termination expansion types, and connects the members of the next level layer by layer along the member reference relationship of the composite types to be expanded. When the termination expansion type is reached, the structure hierarchy expansion stops, forming a type expansion relationship that includes the API type entry, member reference order, termination expansion position, and the actual C++ type of the termination expansion member. The type expansion relationship is then output to the composite type code expansion module. The composite type code expansion module receives type expansion relationships, establishes dedicated serialization processing function generation records and dedicated deserialization processing function generation records for each composite type to be expanded, and generates member-level calls according to member order; when the current member belongs to the composite type to be expanded, it establishes a call pointing to the next level dedicated processing function; when the current member belongs to the terminated expansion type, it stops the structure expansion and retains its real C++ type and member position; after member path integrity check, it forms member-level code call relationships and outputs the member-level code call relationships to the unified member call generation module. The unified member call generation module receives member-level code call relationships, establishes a member call record for each terminated expansion member, including its associated dedicated processing function, member object access location, actual C++ type, serialization call direction, and deserialization call direction, and generates unified member calls pointing to preset serialization overload sets and preset deserialization overload sets in the corresponding dedicated serialization processing function and dedicated deserialization processing function, so that the specific overload rules of the terminated expansion member are not determined in the code generation stage; writes the unified member calls and the next-level dedicated processing function calls corresponding to the composite members into the corresponding dedicated processing functions to form a set of IPC serialization code to be compiled, and outputs the set of IPC serialization code to be compiled to the IPC code generation and compilation verification module; The IPC code generation and compilation verification module receives the set of IPC serialization code to be compiled and the unified semantic model. It forms an API ID mapping relationship based on the API function name, parameter type sequence, and return type, and generates server-side code, adapter code, proxy code, client code, and API ID mapping code. These code, along with the set of IPC serialization code to be compiled, form an inter-process communication code set. The module then compiles the inter-process communication code set, causing the compiler to perform overload resolution in the preset serialization overload set and preset deserialization overload set based on the actual C++ type of the terminated expansion member. Finally, it determines the generation status of the inter-process communication code set based on the compilation status of each generated source file, the API function name consistency check result, and the file integrity check result. The type hierarchy determination module uses the actual C++ type formed by the header file semantic parsing module as the basis for judgment. The composite type code expansion module expands the composite structure layer by layer along the type expansion relationship until the termination expansion member. The unified member call generation module stops the specific overload selection in the code generation stage at the termination expansion position and retains the actual C++ type of the termination expansion member in the IPC code generation and compilation verification module. The IPC code generation and compilation verification module completes the corresponding overload resolution in the compilation stage.

[0095] The above formulas are used to represent the composition of the header file input set, the update of the recursive parsing relationship of user-defined types, and the determination of type expansion conditions, respectively. They belong to set relationship and logical judgment expressions and do not involve data fitting, model training, empirical thresholds, or dimensionless processing of physical quantities. The files, types, member sets, and reference relationships represented by each symbol are all obtained from the aforementioned header file reading and semantic parsing process. The specific meanings and processing conditions are subject to the descriptions of the corresponding steps above.

[0096] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0097] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0098] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.< / t> < / t> < / t>

Claims

1. A method for generating inter-process communication code based on header file semantic analysis, characterized in that, Includes the following steps: S1. Obtain the target C++ header file and dependent header files, parse API functions, structures and type dependencies, recursively parse user-defined types that are not fully defined, and form a unified semantic model that records member relationships, member order and real C++ types. S2. Based on the unified semantic model, user-defined structures with members are identified as composite types to be expanded, and basic types, enumerations, strings, fixed-length arrays, and containers are identified as terminating expansion types, thus forming type expansion relationships. S3. Based on the type expansion relationship, generate dedicated serialization and deserialization functions for the composite type to be expanded, generate calls layer by layer along the member relationship, and stop expansion at the member that terminates the expansion, forming a member-level code call relationship that retains the real C++ type. S4. Based on the member-level code call relationship, generate unified member calls for the serialization overload set and the deserialization overload set in the dedicated processing function, without determining the specific overload rules for the terminated expansion member during the code generation stage, thus forming a set of IPC serialization code to be compiled. S5. Based on the unified semantic model, generate server-side code, adapter code, proxy code, client-side code, and API ID mapping code. Combine these with the IPC serialization code set to be compiled to form an inter-process communication code set and compile it. The compiler will then make overload decisions based on the actual C++ types of the terminated expansion members and determine the generated result based on the compilation status, API function name consistency, and file integrity.

2. The method for generating inter-process communication code based on header file semantic analysis according to claim 1, characterized in that, S1 specifically includes: Read the target C++ header file that serves as the source of the interface definition, recursively obtain the dependent header files that can be located by the current application software development project file path along the include reference relationship in the target C++ header file, do not add the dependent header files that are obtained repeatedly, and form a parsing failure state for dependent header files that cannot be located or read, thus forming a header file input set. Based on the header file input set, extract the function names, return types, parameter order, and parameter C++ types of service classes, namespaces, and API functions. Also extract the member names, member order, member C++ types, enumerations, type aliases, and header file dependency information of structures to form an initial semantic information set. An initial set of types to be resolved is established from the parameter types and return types of API functions, as well as user-defined types referenced by struct members, type aliases, and container elements that have not yet been fully defined.

3. The method for generating inter-process communication code based on header file semantic analysis according to claim 2, characterized in that, It also includes: recursively parsing user-defined types until no new user-defined types are generated that have not yet been parsed, and organizing the parsed service classes, API functions, struct member relationships, enumerations, type aliases and type dependencies into a unified semantic model.

4. The method for generating inter-process communication code based on header file semantic analysis according to claim 1, characterized in that, S2 specifically includes: Establish an API type entry set from the API function parameter types and return types in the unified semantic model, and form a type description record for each entry type. The type description record should include at least whether it is a user-defined structure, the number of members, an ordered list of members, the C++ type of the members, whether it belongs to a basic type, an enumeration, a string, a fixed-length array or container, and the corresponding element type. Type hierarchy is determined based on type description records. User-defined structures with members are identified as composite types to be expanded, while basic types, enumerations, strings, fixed-length arrays, and containers are identified as terminated expansion types. The actual C++ types of each type and its members are preserved. User-defined structures with zero members and no corresponding dedicated processing function are classified as unsupported types. Start with the parameter and return types of each API function to establish the type expansion starting point, and connect the members of the next level layer by layer along the member reference relationships of the composite type to be expanded.

5. The method for generating inter-process communication code based on header file semantic analysis according to claim 4, characterized in that, Also includes: When the type of the terminating expansion is reached, the structural hierarchy expansion stops, forming a type expansion relationship that includes the API type entry, the order of member references at each level, the terminating expansion position, and the actual C++ type of the terminating expansion member.

6. The method for generating inter-process communication code based on header file semantic analysis according to claim 1, characterized in that, S3 specifically includes: Read the type expansion relationship, establish a dedicated serialization processing function generation record and a dedicated deserialization processing function generation record for each composite type to be expanded, and associate them with the ordered member list of the composite type to be expanded, so that the same composite type to be expanded corresponds to a set of dedicated processing functions to be generated; Process each member sequentially according to the ordered member list. When the current member belongs to the composite type to be expanded, establish member-level calls pointing to the next-level dedicated processing function in the corresponding dedicated serialization processing function and dedicated deserialization processing function respectively. When the current member belongs to the type to be terminated, stop the structure expansion and retain the actual C++ type and member position of the member. Check whether each composite type to be expanded has corresponding two types of dedicated processing function generation records, whether each member has a unique subsequent processing state, and whether each structure path can reach the terminating expansion type. Organize the dedicated processing function generation records, member order, next-level call relationship, the actual C++ type of the terminating expansion member, and member position into member-level code call relationship.

7. The method for generating inter-process communication code based on header file semantic analysis according to claim 1, characterized in that, S4 specifically includes: Read the member-level code call relationship, and create a member call record to be bound for each terminated expansion member. The member call record to be bound includes the exclusive processing function, the member object access location, the real C++ type, the serialization call direction, and the deserialization call direction. For each member call record to be bound, a unified member call is generated in the corresponding dedicated serialization processing function and dedicated deserialization processing function, pointing to the preset serialization overload set and the preset deserialization overload set. The overload set includes at least the C++ function or template overloads corresponding to basic types, enumerations, strings, fixed-length character arrays, fixed-length byte arrays and containers. The unified member call retains the real C++ type of the terminated expansion member and does not determine the specific overload during the code generation stage.

8. The method for generating inter-process communication code based on header file semantic analysis according to claim 7, characterized in that, Also includes: Write the unified member call and the next-level dedicated processing function call corresponding to the composite member into the corresponding dedicated processing function, check the integrity of each member processing statement, member order, real C++ type and required header file reference, and organize the dedicated processing functions and member calls that pass the check into a set of IPC serialization code to be compiled.

9. The method for generating inter-process communication code based on header file semantic analysis according to claim 1, characterized in that, S5 specifically includes: Based on a unified semantic model, an API ID mapping relationship is formed according to the API function name, parameter type sequence, and return type. Server-side code, adapter code, proxy code, client-side code, and API ID mapping code are generated respectively. The set of IPC serialization code to be compiled and the aforementioned generated code are combined to form an inter-process communication code set. The g++ function compiles the source files in the inter-process communication code set, and the compiler performs overload resolution in the preset serialization overload set and preset deserialization overload set according to the actual C++ type of the terminated expansion member. If a matching overload exists, compilation continues; if no matching overload exists, the types are incompatible, or the necessary declaration is missing, the compilation failure status and compilation error information are output. Based on the compilation status of each generated source file, API consistency checks are performed using the API function names in the unified semantic model as a comparison benchmark, and file integrity checks are performed based on the expected file list. If any check fails, a failure status and error report are output. If all checks pass, the set of inter-process communication code is determined as the verified generated code.

10. A system for generating inter-process communication code based on header file semantic analysis, employing the method for generating inter-process communication code based on header file semantic analysis as described in any one of claims 1 to 9, characterized in that, include: The module includes a header file semantic parsing module, a type hierarchy determination module, a composite type code expansion module, a unified member call generation module, and an IPC code generation and compilation verification module.

Images