Spaces:
Runtime error
Runtime error
| Type conversions | |
| ################ | |
| Apart from enabling cross-language function calls, a fundamental problem | |
| that a binding tool like pybind11 must address is to provide access to | |
| native Python types in C++ and vice versa. There are three fundamentally | |
| different ways to do this—which approach is preferable for a particular type | |
| depends on the situation at hand. | |
| 1. Use a native C++ type everywhere. In this case, the type must be wrapped | |
| using pybind11-generated bindings so that Python can interact with it. | |
| 2. Use a native Python type everywhere. It will need to be wrapped so that | |
| C++ functions can interact with it. | |
| 3. Use a native C++ type on the C++ side and a native Python type on the | |
| Python side. pybind11 refers to this as a *type conversion*. | |
| Type conversions are the most "natural" option in the sense that native | |
| (non-wrapped) types are used everywhere. The main downside is that a copy | |
| of the data must be made on every Python ↔ C++ transition: this is | |
| needed since the C++ and Python versions of the same type generally won't | |
| have the same memory layout. | |
| pybind11 can perform many kinds of conversions automatically. An overview | |
| is provided in the table ":ref:`conversion_table`". | |
| The following subsections discuss the differences between these options in more | |
| detail. The main focus in this section is on type conversions, which represent | |
| the last case of the above list. | |
| .. toctree:: | |
| :maxdepth: 1 | |
| overview | |
| strings | |
| stl | |
| functional | |
| chrono | |
| eigen | |
| custom | |