"vscode:/vscode.git/clone" did not exist on "8f4eb006901553ccfa010b75660f979ab1ef31a4"
  1. 04 Sep, 2020 1 commit
  2. 01 Sep, 2020 1 commit
  3. 23 Aug, 2020 2 commits
  4. 22 Aug, 2020 1 commit
    • jbarlow83's avatar
      Improve documentation of Python and C++ exceptions (#2408) · b8863698
      jbarlow83 authored
      The main change is to treat error_already_set as a separate category
      of exception that arises in different circumstances and needs to be
      handled differently. The asymmetry between Python and C++ exceptions
      is further emphasized.
      b8863698
  5. 20 Aug, 2020 1 commit
  6. 19 Aug, 2020 1 commit
    • Henry Schreiner's avatar
      feat: new FindPython support (#2370) · 1729aae9
      Henry Schreiner authored
      * feat: FindPython support
      
      * refactor: rename to PYBIND11_FINDPYTHON
      
      * docs: Caps fixes
      
      * feat: NOPYTHON mode
      
      * test: check simple call
      
      * docs: add changelog/upgrade guide
      
      * feat: Support Python3 and Python2
      
      * refactor: Use targets in tests
      
      * fix: support CMake 3.4+
      
      * feat: classic search also finds virtual environments
      
      * docs: some updates from @wjakob's review
      
      * fix: wrong name for QUIET mode variable, reported by @skoslowski
      
      * refactor: cleaner output messaging
      
      * fix: support debug Python's in FindPython mode too
      
      * fixup! refactor: cleaner output messaging
      
      * fix: missing pybind11_FOUND and pybind11_INCLUDE_DIR restored to subdir mode
      
      * fix: nicer reporting of Python / PyPy
      
      * fix: out-of-order variable fix
      
      * docs: minor last-minute cleanup
      1729aae9
  7. 16 Aug, 2020 1 commit
  8. 04 Aug, 2020 1 commit
  9. 23 Jul, 2020 1 commit
  10. 20 Jul, 2020 1 commit
  11. 15 Jul, 2020 1 commit
    • Kota Yamaguchi's avatar
      Fix undefined memoryview format (#2223) · e2488698
      Kota Yamaguchi authored
      * Fix undefined memoryview format
      
      * Add missing <algorithm> header
      
      * Add workaround for py27 array compatibility
      
      * Workaround py27 memoryview behavior
      
      * Fix memoryview constructor from buffer_info
      
      * Workaround PyMemoryView_FromMemory availability in py27
      
      * Fix up memoryview tests
      
      * Update memoryview test from buffer to check signedness
      
      * Use static factory method to create memoryview
      
      * Remove ndim arg from memoryview::frombuffer and add tests
      
      * Allow ndim=0 memoryview and documentation fixup
      
      * Use void* to align to frombuffer method signature
      
      * Add const variants of frombuffer and frommemory
      
      * Add memory view section in doc
      
      * Fix docs
      
      * Add test for null buffer
      
      * Workaround py27 nullptr behavior in test
      
      * Rename frombuffer to from_buffer
      e2488698
  12. 07 Jul, 2020 1 commit
  13. 30 Jun, 2020 2 commits
  14. 10 Jun, 2020 1 commit
  15. 26 Apr, 2020 5 commits
  16. 14 Nov, 2019 1 commit
  17. 19 Jul, 2019 1 commit
  18. 22 Jun, 2019 1 commit
  19. 11 Jun, 2019 2 commits
  20. 10 Jun, 2019 5 commits
  21. 16 Nov, 2018 2 commits
  22. 28 Aug, 2018 1 commit
  23. 24 Jun, 2018 1 commit
  24. 24 May, 2018 1 commit
  25. 07 May, 2018 1 commit
  26. 06 May, 2018 2 commits
  27. 14 Apr, 2018 1 commit
    • oremanj's avatar
      Add basic support for tag-based static polymorphism (#1326) · fd9bc8f5
      oremanj authored
      * Add basic support for tag-based static polymorphism
      
      Sometimes it is possible to look at a C++ object and know what its dynamic type is,
      even if it doesn't use C++ polymorphism, because instances of the object and its
      subclasses conform to some other mechanism for being self-describing; for example,
      perhaps there's an enumerated "tag" or "kind" member in the base class that's always
      set to an indication of the correct type. This might be done for performance reasons,
      or to permit most-derived types to be trivially copyable. One of the most widely-known
      examples is in LLVM: https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html
      
      This PR permits pybind11 to be informed of such conventions via a new specializable
      detail::polymorphic_type_hook<> template, which generalizes the previous logic for
      determining the runtime type of an object based on C++ RTTI. Implementors provide
      a way to map from a base class object to a const std::type_info* for the dynamic
      type; pybind11 then uses this to ensure that casting a Base* to Python creates a
      Python object that knows it's wrapping the appropriate sort of Derived.
      
      There are a number of restrictions with this tag-based static polymorphism support
      compared to pybind11's existing support for built-in C++ polymorphism:
      
      - there is no support for this-pointer adjustment, so only single inheritance is permitted
      - there is no way to make C++ code call new Python-provided subclasses
      - when binding C++ classes that redefine a method in a subclass, the .def() must be
        repeated in the binding for Python to know about the update
      
      But these are not much of an issue in practice in many cases, the impact on the
      complexity of pybind11's innards is minimal and localized, and the support for
      automatic downcasting improves usability a great deal.
      fd9bc8f5