[Dune-devel] Replace Dune C++11 by plain C++11

[Christoph Grüninger]

Hi Martin, hi Christian,
you are right, I should have checked the developer meeting 2013 before I
made my changes and should have asked before. Sorry for any inconvenience.
I don't mind to revert these three changes, including Tuesday's one in
localfunctions. But I would like to discuss our decision from Aachen first.

- Support for Visual C++ or XLC was not decided. I know and I support
any reasonable attempt to ease the pain for users of these compilers.
But is the root of compatibility problems the C++11 classes? I doubt that.

- I dislike the idea of an abstract compatibility. We are just guessing
which features might be harmfull. For Intel compiler Steffen checked
which features are compatible and which not. For XLC I was even unable
to find a feature matrix. All I got was an outdated
"C++0xCompilerSupport" from Apache's abandoned Stdcxx project.

- Is XLC still under development? The last release is almost two years
old and I couldn't find a roadmap or planned changes. Not a good basis
for decisions.

- For Visual C++ my changes should be compatible modulo bugs. According
to Microsoft's documentation their newest compiler supports
static_assert, shared_ptr, unique_ptr, tuple, array and much more. But
as nobody uses it, nobody can be shure and makes guesses.

- Where are all the users of these compilers? For example Intel compiler
users: Have a look at FS#1228. Nobody was willing to answer Steffen's
question for almost a year. And one month after Markus proposed a patch
(right before our release!) it was me to ask a co-worker for his cluster
account to test this.
Sorry, but I doubt this very compatibility issues was this pressing.

- Since 2011 dune/common/singleton.hh includes <memory> and uses
std::auto_ptr. Nobody complained so far.

- Now I replaced auto_ptr by unique_ptr. Should we introduce a
dune/common/std/unique_ptr.hh? It will be tricky to ensure that no C++11
classes sneaks into the core modules.

- Is it really worth the hassle to force people to use Dune-C++11
instead of C++11? How should I explain a user that he/she has to use
dune_static_assert and Dune::std::shared_ptr instead of the usual C++ stuff?

- The general interest in this topic is rather low. See FS#1375
(Problems with New Namespace Dune::std), since October nobody answered
Carsten's proposal.

We decided to support GCC 4.4 but have a contradicting decision
regarding classes like array, tuple, shared_ptr and so on. Why should we
gift-wrap all the C++11 candy in a Dune namespace?

Aren't there more pressing issues than converting our current namespace
wrapping to yet another namespace wrapping? And after 3.0 we'll do that
again and finally get rid of it?

Up to now, we still can change our mind because most of the code is
still untouched.

We are facing a major release which won't be backwards compatible. Is it
really that bad to leave the XLC users behind with a Dune 2.3. Hopefully
2.3 will receive more love and some backporting of bugs fixes because at
some point it won't be easy for third party modules to stay compatible
with both 2.3 and 3.0.

== tl;dr ==
(Too long; didn't read)
I am not happy with our decision and would like to hear your opinion.

Bye
Christoph

-- 
... as Sir Cyril Hinshelwood has observed ...fluid dynamicists
were divided into hydraulic engineers who observed things that
could not be explained and mathematicians who explained things
that could not be observed.                 -- James Lighthill
*********************************************
CMWR 2014: 10th - 13th June 2014 in Stuttgart
         Please visit www.cmwr14.de
*********************************************

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20140227/0f06c229/attachment.sig>