mirror of
https://gitlab.com/kicad/code/kicad.git
synced 2024-11-24 23:25:02 +00:00
44 lines
1.5 KiB
ReStructuredText
44 lines
1.5 KiB
ReStructuredText
.. _type-conversions:
|
|
|
|
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
|