I use that by default for compiling Python bindings. It should not make any
difference for just a single file (including this testcase), but I found that
it yields consistently smaller shared libraries when dealing with lots of
compilation units.
Wenzel
> On Oct 20, 2015, at 1:33 PM, Neal Beck
I noticed you used -flto when building the shared libs. Do you find this
makes a difference?
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig
Hi,
I became curious about this myself and ran a simple benchmark for automatically
generated binding code of increasing size.
The compilation times for Boost.Python and pybind11 turn out to be fairly
similar. However, there is a significant difference in terms of the size of the
compilation r
Code: https://github.com/wjakob/pybind11
Documentation: http://pybind11.readthedocs.org/en/latest/
Hi Wenzel, it looks excelent.
There are a few points in boost::python which have been unresolved for a
long time: straightforward support for aligned types (Eigen comes to
mind) and some subtle
This looks really neat!
Do you have any measure on the memory/cpu performance wrt Boost.Python when
compiling large bindings? I would expect that variadic templates and all
the other C++11 goodies are more efficient than the preprocessor magic used
in Boost Python, from this point of view.
Cheers
Hi,
it would take a long time to discuss all differences, but I can give some
examples. There are basically three ways of interfacing with Python objects in
pybind11.
1. using wrapper classes like pybind11::object (analogous to
boost::python::object)
2. by creating bindings that map a C++ type
At first glance, this looks great. I've been tinkering with something like
this for a while now, but it's never amounted to anything more than a C++11
learning project, and this looks quite solid in comparison.
It may be a long time before I get a chance to evaluate pybind11 for use in
my own pro
On 19.10.2015 06:24, Wenzel Jakob wrote:
> I would be open to it but have my doubts about the feasibility of a
> merge. Consider the difference in code size alone: Boost.Python
> (without dependencies like MPL etc.) uses 26K lines of code, compared
> to about 2K for pybind11 (3K with all extensions
kob
>> To: cplusplus-sig@python.org
>> Sent: Sunday, October 18, 2015 2:56 PM
>> Subject: [C++-sig] pybind11 -- alternative to Boost.Python
>>
> It looks good.
> Have you tried contacting the actual boost.python mantainer and maybe propose
> merge with the boo
>
> From: Wenzel Jakob
>To: cplusplus-sig@python.org
>Sent: Sunday, October 18, 2015 2:56 PM
>Subject: [C++-sig] pybind11 -- alternative to Boost.Python
>
>
>
>Hello all,
>
>
>after being a long-time Boost.Python user, I’ve b
Wow the docs and examples look great!
Thank you for the tremendous amount of work you put in!
I am eager to test this with CUDA7+/C++11 programs.
Best,
Axel
On October 18, 2015 3:56:42 PM EEST, Wenzel Jakob wrote:
>Hello all,
>
>after being a long-time Boost.Python user, I’ve been working on an
Hello all,
after being a long-time Boost.Python user, I’ve been working on an alternative
that makes more effective use of recent C++11-capable compilers. The overall
syntax and ideology are very similar to Boost.Python, but the implementation
only requires a few header files with a a vastly sm
12 matches
Mail list logo
