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

Sean Farley sean at farley.io
Mon Feb 8 17:40:12 EST 2016


Danek Duvall <danek.duvall at oracle.com> writes:

> Kyle Lippincott wrote:
>
>> On Mon, Feb 8, 2016 at 1:33 PM, Sean Farley <sean at farley.io> wrote:
>> 
>> >
>> > Laurent Charignon <lcharignon at fb.com> writes:
>> >
>> > > # HG changeset patch
>> > > # User Laurent Charignon <lcharignon at fb.com>
>> > > # Date 1454965979 28800
>> > > #      Mon Feb 08 13:12:59 2016 -0800
>> > > # Branch stable
>> > > # Node ID 3c1ae9c7e93e8556fa7470919108a02bd989d040
>> > > # Parent  61f4d59e9a0be4e25c1aa016db1a80a540a9d337
>> > > RFC: allow optional C++ 11 extensions with pybind11 for performance code
>> >
>> > I am very much against this as I am also against writing code in rust /
>> > go / etc. Mercurial is a *system tool*. When cloning code on IBM
>> > BlueGene it is annoying as hell to have random dependencies sneak in
>> > like this. For reference, IBM BlueGene has had problem with codes that
>> > use C++.
>> >
>> 
>> Do you have links to some of the issues?  I feel like C++ is common enough
>> and mature enough that this is mostly cargo-culted fear, but would be fine
>> with being proven wrong.
>> 
>> I don't know about the portability of pybind11 or any of those, but I was
>> definitely under the impression that C++03 code was essentially as portable
>> as C, and C++11 was getting close.
>
> There's also the issue of ABI compatibility, which I believe is also
> getting close to sane, but is not quite there yet.  Which means that
> everyone working within a particular ecosystem has to use the same version
> of the same compiler, or risk some pretty nasty blow-ups.
>
> Solaris tries *very* hard to stay away from C++ -- there's no safe way to
> use it except in dumb applications that will never load third-party code.
> I know Solaris isn't mercurial's biggest market, and I'm sure I can hack
> something together that'll work for us, but I anticipate this being a huge
> pain in the rear in the long term.

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.


More information about the Mercurial-devel mailing list