[petsc-dev] C++11, compatibility versus simplicity

[Karl Rupp]

Hey,

 > Elemental headers now require C++11, so we have to deal with C++11.

Oh no, Jack couldn't resist the temptation...


> It's worth noting that C++11 is not strictly backward-compatible with
> C++03.  For example, the following is an error with C++11 due to an
> implicit narrowing conversion.
>
>    float foo(float x) {
>      float a[] = {x-.5, x+.5};
>      return a[0] + a[1];
>    }

One will also stumble upon implicit conversions in std::pair<T, U> if 
the arguments are not of type T und U, but only something that can be 
converted. This is for example of interest when calling insert() on a 
std::map<>.


> I haven't tried compiling all of PETSc with C++11 enabled, but I think
> we'll encounter the narrowing issue above and have to add some casts.
> We can do that, but not so for third-party libraries.

Note that recent Visual Studio compilers use C++11 by default, I'm not 
even sure whether one can switch this off. Since I don't remember any 
specific complaints from our Windows users, it seems to be okay.


> The most compatible choice (in terms of having the compiler accept)
> would be to add a "dialect" system so that we can compile matelem.cxx
> with C++11 support, but other C++ files with an older standard.  The
> problem with this is that the C++11 ABI (on most compilers) is not
> entirely compatible with the C++98 ABI.
>
>    http://gcc.gnu.org/wiki/Cxx11AbiCompatibility
>
> This means that to be safe, all libraries in the stack should be
> compiled with -std=c++11.  So despite the source compatibility issues, I
> think we have to make C++11 a global choice and complain to third
> parties if they can't build with it.

Although painful, this seems to be the only reasonable path to go.


> I think this means adding a package requirescxx11 and adding compiler
> detection for the appropriate flags.

This should be sufficiently extensible even with future standards. It 
seems like the next will be in 2014 (minor 'fixes') and then a more 
extensive update in 2017. Let's see, C++0x turned out to be too 
optimistic... ;-)

Best regards,
Karli