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

[Danek Duvall]

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.

Danek