[PATCH RFC] RFC: allow optional C++ 11 extensions with pybind11 for performance code

[Ryan McElroy]

On 2/8/2016 23:55, Sean Farley wrote:
> timeless <timeless at gmail.com> writes:
>
>> Sean Farley <sean at farley.io> wrote:
>>> Yes, this is precisely the experience I have with C++ and libc++ (yuck
>>> and gross incompatibility with libstdc++). It's not just Solaris,
>>> either. Try anything that is not {Linux, Windows, Mac} / {gcc, clang}
>>> and you'll see all kinds of corner cases crop up.
>> There are plenty of painful corner cases on Windows too.
>> And if you try hard enough you can get plenty of annoying corner cases on Linux.
>>
>> Would a CFront style approach be good enough? Write in limited C++,
>> use llvm to convert it to C, commit the C++ as source and the
>> generated C and have the build system use the generated C?
> I'd rather not go down this route. It's a little too close to switching
> languages completely.
>
> By writing in C++ we are making it harder for us in the future to use
> pypy. I think we can all agree that writing Python C is annoying
> (opposed to just straight C). One way forward could be:
>
> - write standard C, creating a shared library
> - use cffi for binding to that
>
> The benefit is that we can use our C code for pypy. The downside is that
> we introduce a cffi dependency.

I didn't know what cffi was, and I wanted to know more about it. I found 
this page which was useful: https://cffi.readthedocs.org/en/latest/

Specifically, the "Goals" section compares to to, eg, CPython. It sounds 
useful, especially if we want to go towards pypy in the future.