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
