The source code and dockerfile for the GSW2024 AI Lab.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
This repo is archived. You can view files and clone it, but cannot push or open issues/pull-requests.

42 lines
1.5 KiB

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