Python and C + + cross-language signal interaction method and system

Abstract

The invention relates to the technical field of computer software hybrid programming and cross-language interaction, and provides a Python and C + + cross-language signal interaction method, which comprises the following steps: S1, performing signal interaction initialization, setting object identification attributes for an object to be interacted by a C + + end through a setProperty () method, and registering metadata of the object to be interacted to a development framework meta-object system; s2, signal discovery is carried out, a Python end traverses a development framework object tree, and a to-be-interacted object of a target C + + with object identification attributes and signals contained in the to-be-interacted object are identified in a signal interaction initialization stage through attribute matching; s3, carrying out signal connection, dynamically establishing a binding relationship between a signal and a slot function, and completing cross-language type system adaptation; and S4, cross-language system operation is carried out, after a C + + end transmits a signal, the signal is automatically routed to a Python end through a development framework event system, a corresponding slot function is triggered for processing, and cross-language signal transmission is realized. The problem that a traditional scheme depends on a complex tool chain and needs to maintain an interface definition file is avoided.

Description

Technical Field

[0001] This invention relates to the technical field of computer software hybrid programming and cross-language interaction, and in particular to a method and system for cross-language signal interaction between Python and C++. Background Technology

[0002] With the continuous development of Electronic Design Automation (EDA) technology, modern EDA platforms have become indispensable core tools in fields such as chip design and circuit simulation. Their feature richness and user customization flexibility directly affect design efficiency and output quality. As users' personalized needs for EDA platforms continue to increase, developing and embedding custom simulator modules on the basis of existing platforms has become an important way to meet specific design scenarios and optimize workflows.

[0003] For these types of custom simulator modules, the implementation of interactive functionality is crucial. To facilitate users' intuitive configuration of simulation parameters, real-time monitoring of simulation operation status, and clear viewing of simulation results, the industry commonly uses Python to develop interactive dialog boxes. Python has significant advantages in the ease of interface development and the flexibility of data processing, enabling the rapid creation of interactive interfaces that conform to user operating habits, effectively lowering the development threshold for custom modules.

[0004] However, it should be noted that, considering that the main interface of an EDA platform needs to handle complex business logic processing, high-frequency data operations, and efficient adaptation to underlying hardware, its development generally chooses the C++ language. The characteristics of C++ in terms of execution efficiency, memory management precision, and system-level development compatibility can ensure that the main interface of the EDA platform has stable and efficient running performance. Therefore, the main interface of most modern EDA platforms is a native C++ development version.

[0005] This difference in technology selection directly leads to the need for cross-language interaction: the simulator's interactive dialog box developed in Python must establish a reliable and efficient communication link with the platform's main interface developed natively in C++. The two need to achieve real-time transmission of information such as simulation parameters, control commands, and result data—for example, simulation parameters set by the user in the Python interactive dialog box must be accurately synchronized to the C++ main interface; state changes occurring in the C++ main interface during simulation must be promptly reflected in the Python interactive dialog box; and result data after simulation completion must also be efficiently transmitted from the C++ end to the Python end for display. Only by achieving this seamless cross-language interaction can the continuity of the user's operation process be guaranteed, avoiding simulation interruptions or result deviations caused by data delays or command loss, ultimately providing users with a smooth and reliable user experience.

[0006] However, current industry-standard technologies for achieving cross-language interaction between Python and C++ all have insurmountable limitations and cannot meet the practical application needs of modern EDA platforms. Specific problems include: Firstly, while solutions like Boost.Python have been used in some cross-language calling scenarios, their core design is not adapted to development frameworks. Development frameworks, as commonly used graphical interfaces and application frameworks in EDA platform development, rely on their meta-object system, which is the core of the signal and slot mechanism. Boost.Python cannot support the signal exposure functionality of development frameworks, nor can it effectively integrate with their meta-object system. This results in the Boost.Python solution being unable to establish a signal transmission channel between the C++ and Python sides in EDA platforms developed based on these frameworks. The core function of cross-language interaction is directly hindered, failing to meet the communication requirements between the simulator module and the main interface.

[0007] Secondly, while the SIP solution can achieve cross-language interaction between Python and C++ to a certain extent and provides some support for development frameworks, its development and maintenance costs are too high, and the process is extremely cumbersome. When using the SIP solution, developers first need to write and continuously maintain dedicated interface definition files (.sip files). These files must precisely describe the mapping relationship between C++ classes, functions, data types, and the Python side. Any changes to the C++ code may require simultaneous modifications to the interface definition file, increasing development complexity and workload. Simultaneously, the SIP solution relies on a specific toolchain for code generation and compilation, and the configuration, updates, and compatibility handling of this toolchain consume significant time. Furthermore, during actual compilation and execution, the SIP solution automatically generates a large amount of redundant intermediate code. This code not only occupies additional storage space but may also increase the system's runtime burden and reduce the response speed of cross-language interaction, contradicting the EDA platform's requirements for lightweight and high-efficiency operation.

[0008] In summary, neither of the current mainstream cross-language interaction solutions, Boost.Python and SIP, can effectively solve the core problem of "efficient signal interaction between Python interactive dialog boxes and the C++ main interface" in modern EDA platforms. The former is limited by the compatibility of development frameworks and cannot achieve signal transmission; the latter, due to its complex development and maintenance and the existence of redundant intermediate code, fails to meet the requirements of lightweight design and high efficiency. This technical bottleneck not only restricts the functionality of custom simulator modules but also affects the overall performance and user experience of the EDA platform, urgently requiring a better technical solution to overcome the existing limitations. Summary of the Invention

[0009] To address the aforementioned issues, the present invention aims to provide a method and system for cross-language signal interaction between Python and C++. This method achieves cross-language signal interaction between Python and C++ based on a development framework through a four-stage process. It avoids the problems of traditional solutions relying on complex toolchains, requiring the maintenance of interface definition files, and generating redundant intermediate code. This results in lightweight and highly efficient cross-language signal transmission, meeting the high-efficiency interaction requirements of Python custom simulator interactive dialog boxes and C++ main interfaces in modern EDA platforms, and improving the flexibility, execution efficiency, and user experience of hybrid programming.

[0010] The above-mentioned objective of this invention is achieved through the following technical solutions: A method for cross-language signal interaction between Python and C++ includes the following steps: S1: Initialize signal interaction. In the C++ side, the setProperty() method is used to set the object identifier property for the object to be interacted with, and the metadata of the object to be interacted with is registered to the development framework meta-object system. S2: Perform signal discovery. The Python side traverses the development framework object tree and identifies the target C++ object to be interacted with and the signals it contains by setting the object identifier attribute in the signal interaction initialization phase through attribute matching. S3: Perform signal connection, dynamically establish the binding relationship between the signals of the target C++ object to be interacted with and the Python end slot function, and complete cross-language type system adaptation; S4: Enables cross-language system operation. After the C++ side emits a signal, the event system of the development framework automatically routes the signal to the Python side, triggering the corresponding slot function for processing, thus realizing cross-language signal transmission.

[0011] Furthermore, in step S1, the object identification attribute is a unique custom attribute used to distinguish target objects in the development framework object system; the metadata registration is completed based on the QMetaObject interface of the development framework meta-object system, and the registration content includes class meta-information such as signals that the target object can emit and supported slot functions, so that the development framework can identify the metadata characteristics of the target object.

[0012] Further, in step S2, the Python side obtains the top-level window list through the interface provided by the development framework, and traverses the development framework object tree based on the top-level window list. During the traversal, the target C++ object to be interacted with is found by comparing the object identifier attribute set in the signal interaction initialization stage. When identifying the signal of the target C++ object to be interacted with, the detailed information of the signal, including its name and parameter type, is obtained using the interface of the development framework meta-object system.

[0013] Furthermore, in step S3, the binding relationship between the signals of the target C++ object to be interacted with and the Python end slot function is dynamically established through the QObject::connect() method of the development framework; type system adaptation includes the conversion between basic data types and custom data types. The conversion of basic data types is handled by the development framework and Python's native type conversion mechanism, and the conversion of custom data types ensures the accuracy of cross-language transmission by registering custom types.

[0014] Furthermore, in step S4, the C++ side emits a signal through the QObject::emit() method, and the timing of the emission is triggered by the business logic; the development framework event system routes the signal according to the binding relationship between the signal of the target C++ object to be interacted with and the slot function of the Python side established in step S3, and executes the code by means of the embedded interface of the Python interpreter when calling the Python slot function.

[0015] Furthermore, the object identifier attribute set in step S1 is a string type. Before setting it, the object identifier attribute of existing objects in the development framework object system will be traversed to check for duplicates. If duplicates are found, a prompt will be given or automatic adjustment will be made to ensure the uniqueness of the object identifier attribute.

[0016] Furthermore, in step S3, for the adaptation of the custom data type, the custom data is converted into a general data form supported by the development framework meta-object system by defining serialization and deserialization methods on the C++ side, and the general data form is restored to the custom data type on the Python side, thereby realizing cross-language custom data transmission.

[0017] A Python-C++ cross-language signal interaction system for implementing the Python-C++ cross-language signal interaction method described above includes: The initialization phase module is used to initialize signal interaction. In the C++ side, the setProperty() method is used to set the object identification property of the object to be interacted with, and the metadata of the object to be interacted with is registered to the development framework meta-object system. The discovery phase module is used for signal discovery. The Python side traverses the development framework object tree and identifies the target C++ object to be interacted with and the signals it contains by setting the object identifier attribute in the signal interaction initialization phase through attribute matching. The connection phase module is used to perform signal connection, dynamically establish the binding relationship between the signals of the target C++ object to be interacted with and the Python end slot function, and complete cross-language type system adaptation; The runtime module is used for cross-language system operation. After the C++ side emits a signal, the event system of the development framework automatically routes the signal to the Python side, triggering the corresponding slot function for processing, thus realizing cross-language signal transmission.

[0018] A computer device includes a memory and one or more processors, the memory storing computer code that, when executed by the one or more processors, causes the one or more processors to perform the method described above.

[0019] A computer-readable storage medium storing computer code that, when executed, performs the method described above.

[0020] Compared with the prior art, the present invention has at least one of the following beneficial effects: (1) Lightweight interactive architecture, free from dependence on complex toolchains: This invention adopts a lightweight attribute marking mechanism to replace the heavy interface binding that relies on Boost.Python, SIP, etc. in the traditional solution. Object recognition is achieved through the setting-discovery mode of "C++ side sets a unique identifier - Python side locates and identifies". Specifically, the C++ side sets a unique identifier for the object to be interacted with based on the development framework attribute system, and the Python side completes the target object location and signal discovery based on the development framework object tree traversal and pattern matching algorithm. This effectively avoids dependence on complex binding toolchains, eliminates the need to maintain interface definition files, and successfully realizes a lightweight cross-language signal interaction architecture with zero interface definition and no intermediate layer, which greatly reduces development complexity and maintenance costs.

[0021] (2) Improve the flexibility and execution efficiency of hybrid programming: Compared with the limitations of traditional solutions that require generating redundant intermediate code and adapting to fixed interfaces, this invention can flexibly adapt to the cross-language signal interaction requirements in different business scenarios through lightweight attribute marking and dynamic setting-discovery mode, without the need to pre-fix the interaction logic; at the same time, the zero interface definition and no intermediate layer design reduces the redundant links in signal transmission, and combined with the efficient event handling capabilities of the development framework, it significantly improves the flexibility of Python and C++ hybrid programming and the execution efficiency of cross-language signal interaction.

[0022] (3) Adapt to the development framework ecosystem and ensure interaction stability: The solution is based on the development framework's attribute system, meta-object system and event system throughout the process, which fully matches the technical characteristics of the development framework. It ensures that the C++ side identifier setting, Python side object traversal recognition, signal routing and other links have good compatibility and stability, avoiding the problems of signal loss and type incompatibility that are easy to occur in traditional non-development framework native solutions, and providing reliable technical support for cross-language signal interaction. Attached Figure Description

[0023] Figure 1 This is an overall flowchart of the Python and C++ cross-language signal interaction method of the present invention; Figure 2 This is an interactive diagram illustrating the cross-language signal interaction method between Python and C++ of the present invention. Figure 3 This is a diagram showing the overall structure of the Python and C++ cross-language signal interaction system of this invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0026] First Embodiment like Figure 1 and 2 As shown, this embodiment provides a cross-language signal interaction method between Python and C++, characterized by the following steps: S1: Initialize signal interaction. In the C++ side, the setProperty() method is used to set the object identifier property for the object to be interacted with, and the metadata of the object to be interacted with is registered to the development framework meta-object system.

[0027] In this embodiment, in step S1, the object identification attribute is a unique custom attribute used to distinguish target objects in the development framework object system; the metadata registration is completed based on the QMetaObject interface of the development framework meta-object system, and the registration content includes class meta-information such as signals that the target object can emit and supported slot functions, so that the development framework can identify the metadata characteristics of the target object.

[0028] In this embodiment, the core of step S1 is to "assign an identity" to the object to be interacted with on the C++ side and "synchronize metadata to the development framework system," ensuring that the Python side can accurately locate the object and identify its interactive signals. Specific technical details and examples are as follows: I. Design and Function of Object Identification Attributes The object identifier attribute is a "unique identification code" for the object to be interacted with on the C++ side, and it must satisfy both global uniqueness and business identifiability: Uniqueness Design: This attribute is a developer-defined development framework attribute (which needs to be declared in the C++ class via the Q_PROPERTY macro). The value must be ensured to be unique throughout the entire development framework object tree. For example, in an EDA platform scenario, if the object to be interacted with is the control module of a "transistor parameter simulator", the identifier attribute can be set to the string type "Simulator_Transistor_Control_Module_001", where "Transistor" clearly defines the module function and "001" avoids duplicate identifiers for modules of the same type. Mechanism of action: In the development framework object system, all interface elements and functional modules exist in the form of objects and form a tree structure (i.e., the development framework object tree). The Python side needs to traverse this tree to find the target object, and this identifier attribute is the "search keyword" - if this attribute is not set, the Python side cannot distinguish the C++ module that needs to be interacted with from the massive development framework objects, which may lead to incorrect connection to irrelevant objects or omission of the target object.

[0029] II. Implementation and Significance of Metadata Registration Metadata registration synchronizes the "functional information" of a C++ object to be interacted with to the development framework's meta-object system, enabling the development framework to "understand" the object's interactive capabilities. Specifically, this includes: Based on the interface and registration content: Registration is completed through the QMetaObject interface (such as QObject::metaObject()) of the development framework meta-object system. The registration content covers class meta information - the core of which includes the signals that the object can emit (such as the "simulation parameter update complete" signal signal_ParamUpdateFinished(doublevoltage, double current) in the EDA platform), the supported slot functions (such as the "receive Python start and stop command" slot_ReceiveStartStopCmd(bool isStart)), and also includes basic information such as the object's class name and parent object association; Example Explanation: Suppose the C++ object to be interacted with is a "simulation progress display module," which can emit a "progress update" signal `signal_ProgressUpdated(int progress)` (the parameter is the current simulation progress percentage). When registering metadata, the development framework's meta-object support needs to be enabled via the `Q_OBJECT` macro, and the signal needs to be declared in the class definition (`signals: void signal_ProgressUpdated(int progress);`). After registration, the development framework can obtain information such as the signal's parameter type and number of parameters through `metaObject()->method(metaObject()->indexOfSignal("signal_ProgressUpdated(int)"))`, providing data support for subsequent signal recognition and binding establishment on the Python side. Key significance: If metadata registration is not completed, the development framework cannot recognize the signals and slot functions of C++ objects. Even if the Python side finds the target object, it cannot obtain the list of interactive signals, which ultimately leads to the failure of cross-language signal connection. For example, one of the core defects of the traditional Boost.Python solution is that it cannot effectively expose the development framework metadata of C++ objects, making it impossible for the Python side to recognize the signals of C++ objects.

[0030] In addition, the object identifier attribute set in step S1 is of string type. Before setting it, the object identifier attribute of existing objects in the development framework object system will be traversed to check for duplicates. If duplicates are found, a prompt will be given or the attribute will be automatically adjusted to ensure the uniqueness of the object identifier attribute.

[0031] The design and uniqueness verification of the "string type object identifier attribute" in step S1 is a core prerequisite for ensuring that the Python side can accurately locate the target C++ object later. If the identifier attribute is duplicated, the Python side may match multiple unrelated objects when traversing the development framework object tree, leading to misconnected signals and chaotic interaction logic. The choice of string type takes into account both "readability" and "extensibility". Specific technical details and examples are as follows: I. The core reason for choosing the string type as the object's identifier property Compared to other data types such as integers and floating-point numbers, string type identifier attributes are better suited to the actual needs of cross-language interaction scenarios: Business semantics are recognizable: Strings can directly embed information such as the object's function and module affiliation, making it easy for developers to intuitively distinguish objects and reducing maintenance costs. For example, in an EDA platform, the following identifier attributes can be set for C++ objects to be interacted with, based on their different functions: Transistor simulation parameter configuration module: "EDA_Simulator_Transistor_ParamConfig_001" The circuit waveform display control module, "EDA_Display_CircuitWaveform_Control_002", allows direct reading of information such as "Platform (EDA)", "Function Type (Simulator / Display)", and "Specific Module (Transistor_ParamConfig / CircuitWaveform)" from the string, making the purpose of the object clear without having to consult additional documentation.

[0032] Enhanced scalability: When adding similar modules to the system, new identifiers can be flexibly generated by appending serial numbers or suffixes to the end of the string, without needing to refactor the identifier rules. For example, when adding a second transistor simulation parameter configuration module, the identifier can be directly set to "EDA_Simulator_Transistor_ParamConfig_002" without changing the basic format.

[0033] Good cross-language compatibility: Python and C++ have highly consistent string parsing logic, eliminating the need for additional type conversion adaptation. In contrast, if a custom enumeration type or complex structure is used as an identifier, additional type mapping logic needs to be developed in cross-language scenarios, increasing the complexity of interaction.

[0034] II. Implementation Logic and Examples of Uniqueness Verification for Identifier Attributes The core of uniqueness verification is to "scan the identification attributes of existing objects in the development framework's object system before setting the identifier, to avoid duplication." The specific process and examples are as follows: (1) Technical implementation steps of uniqueness verification Before setting the identifier property via setProperty() in the C++ side, the following validation logic is executed: ① Traverse the development framework object tree: call QApplication::allWidgets() or QObject::findChildren provided by the development framework.<QObject*> ( ) Interface: Retrieves all created QObject subclass objects (including UI components, functional modules, etc.) in the current development framework object system; ② Extracts existing identifiers: For each traversed object, extracts its set identifier attribute value through the property("identifier attribute name") interface (e.g., property("EDACppObjectID")), and filters out valid identifiers of string type; ③ Comparison and processing: Performs a full comparison between the new identifier attribute to be set and the existing identifiers: If no duplicates are found, set the property directly using setProperty(). If a duplicate is found, a "prompt + auto-adjustment" mechanism is triggered: First, a warning message is output to the console (e.g., "Warning: Object ID 'EDA_Simulator_Transistor_ParamConfig_001' already exists!"), and then an incrementing sequence number is automatically appended to the end of the new identifier (e.g., the originally planned setting "EDA_Simulator_Transistor_ParamConfig_001" is adjusted to "EDA_Simulator_Transistor_ParamConfig_001_1"), ensuring that the final set identifier is unique.

[0035] (2) Real-world scenario examples Taking the newly added "Capacitor Simulation Parameter Configuration Module" in the EDA platform as an example: The developers initially planned to set the identifier attribute for this module to "EDA_Simulator_Capacitor_ParamConfig_001"; During verification, it was discovered that a "resistance simulation parameter configuration module" already existed in the development framework object system, and its identifier attribute happened to be "EDA_Simulator_Capacitor_ParamConfig_001" (due to oversight in the early development stage, the name was duplicated). System trigger handling mechanism: The console output message reads: "Warning: Object ID 'EDA_Simulator_Capacitor_ParamConfig_001' is duplicated. Auto-adjusting...". The automatic adjustment flag is set to "EDA_Simulator_Capacitor_ParamConfig_001_1", and the setting is completed using setProperty(); When traversing the object tree in Python later, the capacitor simulation module can be accurately matched using "EDA_Simulator_Capacitor_ParamConfig_001_1", avoiding confusion with the existing resistor simulation module and ensuring the accuracy of signal interaction.

[0036] III. The Key Significance of Uniqueness Verification Omitting this verification step may lead to serious interaction failures. For example: Assume that two C++ modules with different functions ("Simulation Startup Control Module" and "Simulation Result Saving Module") are both set to "EDA_Simulator_Control_001"; When the Python side needs to connect to the `signal_SimulationStart()` signal of the "Simulation Start Control Module," traversing the object tree may match two modules simultaneously, potentially leading to an incorrect connection to the "Simulation Result Saving Module." This could cause the user to click "Start Simulation" but trigger the "Save Results" logic instead, completely deviating from business requirements. Therefore, uniqueness verification of identifier attributes is a necessary step to ensure the "accuracy" of cross-language signal interaction and avoid logical confusion caused by duplicate identifiers.

[0037] S2: Perform signal discovery. The Python side traverses the development framework object tree and identifies the target C++ object to be interacted with and its contained signals by setting the object identifier attribute during the signal interaction initialization phase through attribute matching.

[0038] In this embodiment, in step S2, the Python side obtains the top-level window list through the interface provided by the development framework, and traverses the development framework object tree based on the top-level window list. During the traversal, the target C++ object to be interacted with is found by comparing the object identifier attribute set in the signal interaction initialization stage. When identifying the signal of the target C++ object to be interacted with, the detailed information of the signal, including its name and parameter type, is obtained using the interface of the development framework meta-object system.

[0039] In this embodiment, step S2 is the core step of "actively locating the C++ object to be interacted with and identifying its signals" on the Python side. Essentially, it relies on the object management and metadata capabilities of the development framework to "filter targets and extract interaction information" from the complex object system of the development framework, ensuring accurate matching of subsequent signal connections. Its technical logic can be broken down into two main steps: "object location" and "signal recognition," which are illustrated below with an example from an EDA platform scenario: I. Locating the C++ Interactive Object in Python: Traversal Logic from "Top-Level Window" to "Target Object" All UI elements (such as windows, buttons, and functional modules) in the development framework application are built using QObject as the base class, and form a tree structure (i.e., the development framework object tree) according to the "parent-child relationship"—the top-level window (such as the main interface window and simulation sub-window of the EDA platform) is the "root node" of the object tree, and various functional modules (such as the parameter configuration module and progress control module on the C++ side) are the "child nodes" under the root node. The Python side cannot directly know the location of the C++ object, so it needs to locate the target through the process of "top-level window list → object tree traversal → attribute matching". The specific implementation and example are as follows: (1) First step: Get the top-level window list - determine the "starting point range" of the traversal The development framework provides the `QApplication.topLevelWidgets()` interface (which can be called via the PyQt / PySide library in Python). This interface returns all top-level windows (i.e., independent windows visible to the user) in the current application that have no parent object, avoiding the need for the Python side to blindly traverse all objects in the entire application. Example: In an EDA platform, assume there are three currently running top-level windows: Main interface window (title: "EDA Circuit Simulation Platform V2.0") Transistor Simulation Sub-window (Title: "Transistor Parameter Simulation") The waveform analysis sub-window (title: "Simulation Result Waveform Analysis") can obtain object instances of these three windows in Python through QApplication.topLevelWidgets(). Subsequently, it is only necessary to traverse the object tree corresponding to these three windows, without having to deal with other hidden objects unrelated to business (such as system pop-ups, background service objects), which greatly improves traversal efficiency.

[0040] (2) Second step: Traverse the object tree of the top-level window - "dig" the child nodes layer by layer. For each top-level window, the Python side employs a recursive traversal strategy, searching for all its child objects (including direct children, grandchildren, etc.) layer by layer. This is because the C++ interactive object is usually not the top-level window itself, but rather a functional module embedded within the window (such as the "simulation parameter submission module" or "progress display module" within a child window). The traversal logic is as follows: Starting with a top-level window (such as the "transistor simulation child window"), its direct child objects (such as labels, input boxes, and button groups within the child window) are obtained through the `QObject.children()` interface. Then, for each direct child object, `QObject.children()` is called to obtain its next-level child objects, and so on, until the entire object tree corresponding to that window has been traversed. Example: The object tree structure of the "transistor simulation child window" is as follows: Top-level window (transistor simulation child window) → Parameter configuration panel → [C++ interactive object: Transistor parameter submission module] → Submit button. The Python side, through recursive traversal, will delve deeper from the top-level window to the target child object, the "transistor parameter submission module."

[0041] (3) Third step: Attribute matching - locking the "target C++ object" During the traversal, the Python side performs "attribute comparison" on each object: it calls the QObject.property(identifier attribute name) interface (such as property("EDACppObjectID")) to extract the identifier attribute value of the object and performs a full match with the target identifier preset by the C++ side in step S1 (such as "EDA_Simulator_Transistor_ParamSubmit_001").

[0042] If the identifier attribute value of an object is exactly the same as the target identifier, it is determined to be the "target C++ object to be interacted with", and further traversal of that branch is stopped; If there is a discrepancy, continue traversing the child nodes of the object until the entire object tree has been traversed. Example: When traversing the object tree of the "Transistor Simulation Sub-window" in Python, upon encountering the "Transistor Parameter Submission Module," its identifier attribute "EDA_Simulator_Transistor_ParamSubmit_001" is extracted. Since this perfectly matches the preset target identifier, it can be determined that the object is the interactive C++ module, and there is no need to continue traversing its sub-objects such as the "Submit Button."

[0043] II. Recognizing Signals from C++ Objects on the Python Side: Extracting Interaction Information from "Metadata" After finding the target C++ object, the Python side needs to determine "what signals the object can emit" and "what parameters the signals need to transmit"—this information is stored in the development framework meta-object system (registration has been completed in step S1), and the Python side can extract it through the development framework meta-object interface, providing key information for subsequent signal connections.

[0044] (1) Core dependency: "Signal metadata" of the development framework's meta-object system On the C++ side, meta-object support is enabled via the Q_OBJECT macro. After declaring signals in the class (e.g., signals: void signal_ParamSubmitted(double voltage, double capacitance);), the development framework automatically encapsulates the signal information (name, parameter types, number of parameters, etc.) into "metadata" and stores it in a QMetaObject object. On the Python side, the QMetaObject instance can be obtained through the metaObject() interface of the target C++ object, and then the signal information can be extracted.

[0045] (2) Implementation steps and examples of signal recognition Taking the "transistor parameter submission module" (target C++ object) as an example, the specific process for identifying its signals on the Python side is as follows: ① Obtain the meta-object instance: Call the target object's metaObject() method to obtain a QMetaObject instance, which contains all class meta-information of the target object (signals, slot functions, attributes, etc.). ② Traverse all "signal methods": QMetaObject returns the total number of all methods of the object through the methodCount() interface, and obtains the method instance (QMetaMethod) at the specified index through the method(index) interface; at the same time, the methodType() interface of QMetaMethod can determine the method type—if it returns QMetaMethod.Signal, then the method is a "signal". ③ Extract detailed signal information: For each "signal method", extract key information through the QMetaMethod interface: Signal name: name() interface (e.g., if it returns b"signal_ParamSubmitted", the Python side needs to convert it to the string "signal_ParamSubmitted"); Parameter type: parameterTypes() interface (e.g., returning [b"double", b"double"], corresponding to the two parameter types of the signal: voltage (double) and capacitance (double)); Number of parameters: parameterCount() interface (e.g., if it returns 2, it means that the signal needs to pass 2 parameters).

[0046] Example Result: The Python side will eventually recognize that the "transistor parameter submission module" can emit one signal: Signal name: "signal_ParamSubmitted" Parameter type: double (voltage), double (capacitance) Number of parameters: 2. This means that the Python side needs to define a slot function that receives "two double type parameters" and binds it to the signal in order to correctly receive the parameter data submitted by the C++ side.

[0047] III. The key significance of step S2: Avoiding "blind connections" and "incorrect connections" If the "location + recognition" process in step S2 is missing, the Python side will face two major problems: (1) Unable to find the target object: There may be hundreds or thousands of objects in the development framework object tree, and the Python side cannot find the C++ module to be interacted with by "guessing"; (2) Inability to adapt signal parameters: Even if the target object is found by chance, if the signal name and parameter type are unknown, the subsequent signal connection will fail due to "signal name mismatch" or "parameter type incompatibility" (e.g., the Python side defines a slot function that receives an int type parameter, but connects to a C++ side that emits a double type parameter). Therefore, step S2 is a prerequisite for achieving "accurate cross-language signal interaction" and ensures that the Python side can "find and recognize" the target C++ object and its signal.

[0048] S3: Perform signal connection, dynamically establish the binding relationship between the signals of the target C++ object to be interacted with and the Python end slot function, and complete cross-language type system adaptation.

[0049] In this embodiment, in step S3, the binding relationship between the signal of the target C++ object to be interacted with and the Python end slot function is dynamically established through the QObject::connect() method of the development framework; the type system adaptation includes the conversion between basic data types and custom data types. The conversion of basic data types is handled by the development framework and Python's native type conversion mechanism, and the conversion of custom data types ensures the accuracy of cross-language transmission by registering custom types.

[0050] In this embodiment, step S3 is the core step in building a "communication bridge" for cross-language signal interaction between Python and C++. It requires the simultaneous completion of two core tasks: "association of signals and slot functions" and "cross-language parameter type adaptation." This ensures that signals from the C++ side can accurately trigger the processing logic on the Python side, and that parameter transmission is error-free. Specific technical details are explained below in conjunction with the EDA platform scenario: I. Dynamically establish signal-slot binding relationships: Achieve cross-language associations by leveraging the native mechanisms of the development framework. "Dynamic binding" refers to the process where the Python side establishes an association between the signal and the slot function (i.e. the processing function executed after the signal is triggered) in real time based on the signal information of the C++ target object identified in step S2 during the runtime, rather than fixing the binding logic during the compilation stage. This flexibility can adapt to the interaction needs of different business scenarios, and its core relies on the QObject::connect() method of the development framework.

[0051] 1. Technical Implementation Logic The QObject::connect() method of the development framework is the core interface for cross-object signal passing. Essentially, it registers a "signal-slot mapping" through the framework's event system. Regardless of whether the signal originates from a C++ object or the slot function belongs to a Python object (wrapped in a framework-compatible object format by the PyQt / PySide library), this interface breaks down language barriers and establishes a stable connection. When a signal is emitted from the C++ side, the framework's event system automatically retrieves the registered mapping, finds the corresponding Python slot function, and triggers its execution.

[0052] 2. EDA Platform Example Description Taking the "transistor simulation parameter submission" scenario in the EDA platform as an example: In step S2, the Python side has recognized the core signals of the C++ "transistor parameter submission module" (such as the "parameter submission complete signal", which is used to inform the Python side to update the interface display or start the simulation calculation). In the Python side, predefine slot functions (such as the processing logic of "updating the interface after receiving parameters", including displaying the submitted parameters in the interactive dialog box, activating the simulation start button, etc.). When calling the QObject::connect() interface, only three key pieces of information need to be passed in: the C++ target object (transistor parameter submission module), the identified "parameter submission completion signal", and the "interface update slot function" on the Python side; Once the binding is complete, when the user completes the parameter configuration and triggers the signal emission in the C++ side (such as by clicking the "Submit" button), the development framework's event system will directly call the slot function in the Python side, without needing to write additional cross-language calling code, thus achieving seamless interaction of "signal emission triggers processing".

[0053] II. Type System Adaptation: Solving the "Format Difference" Problem in Cross-Language Parameter Passing The type systems of C++ and Python have inherent differences (such as C++'s double and Python's float, C++'s custom structs and Python's classes / dictionaries). Directly passing parameters will result in "parsing errors" (such as truncation of values, type misidentification leading to signal transmission interruption). Therefore, step S3 requires designing adaptation strategies for "basic data types" and "custom data types" respectively to ensure accurate parameter passing.

[0054] 1. Basic data type adaptation: Automatic conversion is achieved by relying on native mechanisms. For basic data types natively supported by both the development framework and Python, such as int (integer, such as simulation progress percentage), double (floating-point, such as voltage and current parameters), and QString (string, such as simulation task name), no additional adaptation logic is needed—the development framework (through the PyQt / PySide library) will automatically complete the type mapping conversion, which is equivalent to a built-in "translator" to ensure that the parameter transmission is accurate.

[0055] 2. Custom data type adaptation: Ensure complete data transmission through type registration. In complex business scenarios (such as EDA platforms transmitting "multi-dimensional simulation configuration information"), it is often necessary to transmit custom data types across languages ​​(such as "simulation configuration structures" defined in C++, containing multiple parameters such as voltage range, frequency, and simulation duration). These types cannot be converted through native mechanisms and require adaptation through "development framework metatype registration + data format unification".

[0056] Technical Implementation Process Registering custom types in C++: via the development framework's qRegisterMetaType <t>The `()` function registers custom data types (such as "simulation configuration structure") with the development framework's meta-object system, informing the development framework that "this type can be used for signal transmission," thus preventing the development framework from refusing to transmit data due to its inability to recognize the type. Unified data transmission format: To ensure that the Python side can parse the data, the C++ side will convert the custom data type into a general format supported by the development framework (such as QByteArray byte stream, which can be understood as "packaging data"). The conversion process needs to encapsulate all parameters in a fixed order (such as encapsulating the voltage range first, then the frequency, and finally the simulation duration). Python side data parsing: After receiving data in a common format, the Python side "unpacks" it according to the encapsulation order of the C++ side, restoring it to a format that Python can process (such as a dictionary or a custom class), ensuring that each parameter corresponds accurately.

[0057] III. The Key Significance of Step S3 Without signal-slot binding, signals emitted by the C++ side will have "no receiver," causing cross-language interaction to be interrupted. Without type system adaptation, parameter passing will result in "formatting errors" (e.g., a double-type voltage value passed by C++ is mistakenly parsed as an int type by the Python side, leading to numerical distortion). Step S3, through the development framework's native mechanisms and layered adaptation strategies, ensures both the "real-time" nature of signal passing (relying on the development framework's event system) and solves the "compatibility" problem of type differences, ultimately achieving a complete cross-language interaction chain where "signals can be triggered and parameters can be parsed."

[0058] Furthermore, in step S3, for the adaptation of the custom data type, the custom data is converted into a general data form supported by the development framework meta-object system by defining serialization and deserialization methods on the C++ side, and the general data form is restored to the custom data type on the Python side, thereby realizing the cross-language transmission of custom data.

[0059] In step S3, the core of cross-language adaptation for custom data types is to solve the problem of C++ and Python custom data structures not being directly recognized through a "serialization-deserialization" conversion process, ensuring that complex business data can be transmitted completely and accurately across languages. The specific implementation logic is based on the idea of ​​a "unified and universal format," as explained below: I. Core Principle: Breaking down language barriers with a "universal data format" Custom data types (such as "simulation configuration structures" in C++ and "circuit parameter classes" in Python) are designed by developers and contain multi-dimensional information (such as numerical values, status indicators, and text descriptions). Their internal structure cannot be directly recognized by the target language. Therefore, the key to adaptation is to "translate" the custom data from both sides into an intermediate format—a common data format natively supported by the development framework's meta-object system (most commonly byte streams, which can be understood as "packaged data blocks"), and then "restore" it to its native data type in the target language.

[0060] This process is similar to "international express delivery": custom data in different languages ​​are like "items of different specifications". They need to be "packaged" (serialized) into standardized packages (universal data form) according to a unified standard. After being transmitted (transported) by signals, they are "unpacked" (deserialized) according to the same standard and restored to the form of items that the recipient can use.

[0061] II. Serialization on the C++ side: Packaging custom data into a generic format On the C++ side, explicit serialization rules need to be defined for custom data types (such as structs and classes) to extract all information from the data in a fixed order and convert it into a general data form (such as byte streams).

[0062] For example, in an EDA platform, the C++ side has a custom data type called "Simulation Task Configuration," which contains four pieces of information: voltage range (numerical), simulation steps (integer), whether to run continuously (boolean), and task name (text). During serialization, this information must be strictly written into the byte stream in the fixed order of "voltage range → simulation steps → whether to run continuously → task name." First, extract the values ​​within the voltage range and convert them into a byte stream format that can be stored. Then extract the integer number of simulation steps and append it to the byte stream in sequence; Next, process the Boolean value for "whether to run continuously" and continue appending; Finally, the text of the task name is converted into a byte stream format and used as the end.

[0063] This "ordered packaging" ensures that the data remains structured in a common format, providing a basis for subsequent reconstruction. Meanwhile, the C++ side also needs to define corresponding deserialization methods (i.e., "unpacking" rules) so that when receiving custom data sent from the Python side, it can be restored to C++'s native data types in the same order.

[0064] III. Deserialization on the Python side: Reconstructing generic data from unpacked data into custom data. After receiving general data (such as byte streams) from the C++ side, the Python side needs to deserialize the data according to the serialization order of the C++ side, extracting the information from the byte stream one by one and restoring it into a custom data form (such as a dictionary or class) that Python can directly use.

[0065] Taking "Simulation Task Configuration" as an example again: After receiving the byte stream, the Python side parses it in the following order: "voltage range → simulation steps → continuity → task name". 1. First, extract the information of the corresponding length from the beginning of the byte stream, convert it into Python floating-point type, and use it as the "voltage range"; 2. Next, extract the next segment of information, convert it to an integer, and use it as the "simulation steps"; 3. Extract the Boolean value information to determine "whether it runs continuously"; 4. Finally, extract the remaining information, convert it into a string, and use it as the "task name".

[0066] After parsing, store this information in a Python dictionary (such as {"voltage range":5.0,"simulation steps":200,...}) or a custom class, and then use it directly in the business logic on the Python side (such as displaying the complete task configuration in the interactive interface).

[0067] If the Python side needs to send custom data (such as modified configurations) to the C++ side, the Python custom data needs to be repackaged into a general form according to the serialization order of the C++ side to ensure that the C++ side can parse it correctly.

[0068] IV. EDA Platform Example: A Complete Custom Data Transfer Process Taking "transferring simulation task configuration from C++ to Python" as an example, the entire process is as follows: 1. Prepare data on the C++ side: Create a "Simulation Task Configuration" instance and fill in the specific information (such as voltage range 5.0V, 200 steps, continuous operation, task name "Transistor Test"); 2. C++ serialization: Packing this information into a byte stream in a fixed order; 3. Signal transmission: Sending byte streams to the Python side via signals; 4. Python-side deserialization: Parse the byte stream in the same order, extract information such as 5.0V, 200 steps, continuous operation, and "transistor test", and store it in a dictionary; 5. Python usage: Read data from a dictionary and display "Task name: Transistor test, voltage range 5.0V, 200 steps (continuous mode)" on the interactive interface.

[0069] Throughout the process, data is transmitted in a universal format, which not only solves the problem of incompatibility across language types but also ensures the integrity and accuracy of all information.

[0070] V. Key Significance: Supporting cross-language interaction in complex business scenarios Without this adaptation mechanism, C++ and Python can only exchange simple, basic data (such as single numbers or text), which cannot meet the needs of complex scenarios such as EDA platforms—for example, it cannot transmit structured data such as simulation configurations containing multiple parameters or circuit node information at once. Through serialization and deserialization adaptation strategies, "unimpeded flow" of custom data types is achieved, enabling cross-language interaction to support more complex business logic while maintaining native compatibility with development frameworks without relying on additional toolchains.

[0071] S4: Enables cross-language system operation. After the C++ side emits a signal, the event system of the development framework automatically routes the signal to the Python side, triggering the corresponding slot function for processing, thus realizing cross-language signal transmission.

[0072] In this embodiment, the C++ side emits signals through the QObject::emit() method, and the timing of the emission is triggered by business logic. The development framework event system routes the signals based on the binding relationship between the signals of the target C++ object to be interacted with and the slot functions of the Python side established in step S3. When calling the Python slot functions, code execution is achieved by using the embedded interface of the Python interpreter.

[0073] In this embodiment, step S4 is the "final execution stage" of cross-language signal interaction. Its core implementation includes the active transmission of signals from the C++ side, the automatic routing of the development framework's event system, and the cross-language calling of Python slot functions, forming a complete closed loop from "signal generation" to "logic response." Its technical logic can be broken down into three key stages: "signal transmission," "signal routing," and "function call," which are explained below in the context of an EDA platform: I. C++ Side Signal Transmission: "Proactive Notification" Driven by Business Logic In C++, the QObject::emit() method emits signals, which essentially sends a notification to the system that "an event has occurred." The timing of the emission is entirely determined by the business logic—that is, when preset interaction conditions are met (such as user operation completion, internal state change, timed task triggering, etc.), the signal emission is automatically triggered without manual intervention.

[0074] The technical essence of signal transmission: QObject::emit() is a signal triggering interface provided by the development framework. Its function is to "inject" signals into the development framework's event system, informing the system that "this signal needs to be processed." In cross-language scenarios, the signals here not only include event types (such as "parameter submission completed" or "simulation progress update"), but may also carry business data (such as specific parameter values ​​or progress percentages). This data has been processed by type adaptation in step S3 to ensure format compatibility.

[0075] II. Signal Routing in the Development Framework Event System: "Precise Delivery" Based on Binding Relationships After the signal is emitted, it is not directly transmitted to the Python side. Instead, the event system of the development framework acts as an "intermediate hub" and automatically "delivers" the signal to the target Python slot function according to the "signal-slot binding relationship" established in step S3 (i.e. the correspondence rules between C++ signals and Python slot functions), ensuring that the signal is not lost or misdelivered.

[0076] 1. Core logic of the routing mechanism The development framework's event system maintains a "signal-slot mapping table" that records all relationships bound via QObject::connect() (including the association between C++ signals and Python slot functions). When a signal is emitted from the C++ side: The event system first identifies the source of the signal (which C++ object) and the signal type (e.g., "parameter submission complete"). Then, retrieve the corresponding Python slot function for the signal from the mapping table; Finally, according to the scheduling rules of the development framework's event loop (such as prioritizing emergency signals and processing normal signals in sequence), the signal and its parameters are passed to the target slot function.

[0077] This mechanism is similar to a "courier sorting system": the signal is the "package", the binding relationship is the "express waybill", and the event system is the "sorting center", ensuring that each "package" can be accurately delivered to the corresponding "recipient" (Python slot function).

[0078] 2. Ensuring routing accuracy Since step S3 has ensured the accuracy of the binding relationship through unique identifier attributes and type adaptation, the event system does not need to make additional judgments during routing and directly executes according to the mapping table, avoiding the risk of "misdirection". III. Python slot function calls: "Cross-language execution" relying on the interpreter embedding interface Python slot functions run in the Python interpreter environment, while C++ and the development framework's event system run in the C++ execution environment; they belong to different "runtime spaces." Therefore, when calling Python slot functions, it is necessary to use the "Python interpreter embedding interface" (i.e., the bridge interface for C++ to call Python code) to achieve an "execution jump" from the C++ environment to the Python environment.

[0079] The purpose of embedding interfaces: Python interpreter embedding interfaces (such as PyRun_SimpleString) allow C++ code to "drive" the Python interpreter to execute specified Python functions. Essentially, it embeds a Python interpreter instance in the C++ process, passes information such as function names and parameters through the interface, and the interpreter is responsible for parsing and executing the Python code, and then returning the execution result to the C++ environment (if needed).

[0080] This mechanism solves the problem of "isolation of execution environments of different languages", allowing signals triggered by C++ to directly drive Python code to run without the need for complex methods such as inter-process communication.

[0081] IV. The Key Significance of Step S4 Step S4 is the "closed-loop endpoint" of the entire cross-language signal interaction: Without a signal transmission mechanism, business events on the C++ side cannot be perceived by the Python side; Without routing in the development framework's event system, signals may "drift without a target" or be "mistakenly delivered to irrelevant functions"; Without an interpreter embedding interface, the C++ environment cannot drive Python code execution, and signal passing will ultimately "not respond".

[0082] Through the coordination of these three stages, a seamless connection is achieved from "C++ event occurrence" to "Python logic response", ensuring the real-time, accuracy and completeness of cross-language interaction, which is especially suitable for complex systems that require multi-language collaboration.

[0083] Second Embodiment like Figure 3 As shown, this embodiment provides a Python-C++ cross-language signal interaction system for executing the Python-C++ cross-language signal interaction method as described in the first embodiment, comprising: The initialization phase module is used to initialize signal interaction. In the C++ side, the setProperty() method is used to set the object identification property of the object to be interacted with, and the metadata of the object to be interacted with is registered to the development framework meta-object system. The discovery phase module is used for signal discovery. The Python side traverses the development framework object tree and identifies the target C++ object to be interacted with and the signals it contains by setting the object identifier attribute in the signal interaction initialization phase through attribute matching. The connection phase module is used to perform signal connection, dynamically establish the binding relationship between the signals of the target C++ object to be interacted with and the Python end slot function, and complete cross-language type system adaptation; The runtime module is used for cross-language system operation. After the C++ side emits a signal, the event system of the development framework automatically routes the signal to the Python side, triggering the corresponding slot function for processing, thus realizing cross-language signal transmission.

[0084] A computer-readable storage medium stores computer code that, when executed, performs the methods described above. Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. This program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0085] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

[0086] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0087] It should be noted that the above embodiments can be freely combined as needed. The above description is only a preferred embodiment of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.< / t>

Claims

1. A cross-language signal interaction method between Python and C++, characterized in that, Includes the following steps: S1: Initialize signal interaction. In the C++ side, the setProperty() method is used to set the object identifier property for the object to be interacted with, and the metadata of the object to be interacted with is registered to the development framework meta-object system. S2: Perform signal discovery. The Python side traverses the development framework object tree and identifies the target C++ object to be interacted with and the signals it contains by setting the object identifier attribute in the signal interaction initialization phase through attribute matching. S3: Perform signal connection, dynamically establish the binding relationship between the signals of the target C++ object to be interacted with and the Python end slot function, and complete cross-language type system adaptation; S4: Enables cross-language system operation. After the C++ side emits a signal, the event system of the development framework automatically routes the signal to the Python side, triggering the corresponding slot function for processing, thus realizing cross-language signal transmission.

2. The Python and C++ cross-language signal interaction method according to claim 1, characterized in that, In step S1, the object identification attribute is a unique custom attribute used to distinguish target objects in the development framework object system; the metadata registration is completed based on the QMetaObject interface of the development framework meta-object system, and the registration content includes class meta-information such as signals that the target object can emit and supported slot functions, so that the development framework can identify the metadata characteristics of the target object.

3. The Python and C++ cross-language signal interaction method according to claim 1, characterized in that, In step S2, the Python side obtains the top-level window list through the interface provided by the development framework, and traverses the development framework object tree based on the top-level window list. During the traversal, the target C++ object to be interacted with is found by comparing the object identifier attribute set in the signal interaction initialization stage. When identifying the signal of the target C++ object to be interacted with, the detailed information of the signal, including its name and parameter type, is obtained using the interface of the development framework meta-object system.

4. The Python and C++ cross-language signal interaction method according to claim 1, characterized in that, In step S3, the binding relationship between the signals of the target C++ object to be interacted with and the Python end slot function is dynamically established through the QObject::connect() method of the development framework; type system adaptation includes the conversion between basic data types and custom data types. The conversion of basic data types is handled by the development framework and Python's native type conversion mechanism, and the conversion of custom data types ensures the accuracy of cross-language transmission by registering custom types.

5. The Python and C++ cross-language signal interaction method according to claim 1, characterized in that, In step S4, the C++ side emits a signal through the QObject::emit() method, and the timing of the emission is triggered by the business logic. The development framework event system routes the signal according to the binding relationship between the signal of the target C++ object to be interacted with and the slot function of the Python side established in step S3. When the Python slot function is called, the code is executed by means of the embedded interface of the Python interpreter.

6. The Python and C++ cross-language signal interaction method according to claim 2, characterized in that, In step S1, the object identifier attribute is set to a string type. Before setting it, the object identifier attribute of existing objects in the development framework object system will be traversed to check for duplicates. If duplicates are found, a prompt will be given or the attribute will be automatically adjusted to ensure the uniqueness of the object identifier attribute.

7. The Python and C++ cross-language signal interaction method according to claim 4, characterized in that, In step S3, for the adaptation of the custom data type, the custom data is converted into a general data form supported by the development framework meta-object system by defining serialization and deserialization methods on the C++ side, and the general data form is restored to the custom data type on the Python side, so as to realize the cross-language custom data transmission.

8. A Python-C++ cross-language signal interaction system for executing the Python-C++ cross-language signal interaction method as described in any one of claims 1-7, characterized in that, include: The initialization phase module is used to initialize signal interaction. In the C++ side, the setProperty() method is used to set the object identification property of the object to be interacted with, and the metadata of the object to be interacted with is registered to the development framework meta-object system. The discovery phase module is used for signal discovery. The Python side traverses the development framework object tree and identifies the target C++ object to be interacted with and the signals it contains by setting the object identifier attribute in the signal interaction initialization phase. The connection phase module is used to perform signal connection, dynamically establish the binding relationship between the signals of the target C++ object to be interacted with and the Python end slot function, and complete cross-language type system adaptation; The runtime module is used for cross-language system operation. After the C++ side emits a signal, the event system of the development framework automatically routes the signal to the Python side, triggering the corresponding slot function for processing, thus realizing cross-language signal transmission.

9. A computer device comprising a memory and one or more processors, the memory storing computer code that, when executed by the one or more processors, causes the one or more processors to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing computer code, wherein when the computer code is executed, the method of any one of claims 1 to 7 is performed.

Images