[PATCH RFC] RFC: allow optional C++ 11 extensions with pybind11 for performance code
Augie Fackler
raf at durin42.com
Tue Feb 9 15:01:59 EST 2016
On Mon, Feb 08, 2016 at 03:55:59PM -0800, 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
>
Writing standard C is actually /worse/ than writing Python C. You have
even fewer nice things to work with (no map type out of the box, but
in Python C you can at least use PyDict). Part of the reason C++
appeals is precisely because it's a widely-available language with
better memory management tools (like smart pointers) and richer standard
tools available (STL collections come to mind).
I don't dispute the idea that it'll make some things harder. I *am*
getting tired of the same old "HPC people can't get their shit
together" song and dance being the reason I can't have any nice things
and have to write a language that's fundamentally stuck in the 70s.
Put another way: I'm totally open to having some way to do cleaner
programming in C, but as it stands the tools we're able to use there
are disastrously difficult and error-prone.
>
> The benefit is that we can use our C code for pypy. The downside is that
> we introduce a cffi dependency.
>
http://doc.pypy.org/en/release-1.9/cppyy.html is a thing for pypy. I
can't speak to its overall value or usabilty, but C++ does not
preclude use of pypy in the future.
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
More information about the Mercurial-devel
mailing list