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

[Martin Nolte]

Hi Christoph,

On 02/27/2014 08:51 AM, Christoph Grüninger wrote:
> 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.
>
That's fine. At least we have a discussion, now.

> - 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.
Wow, Microsoft did really support Compiler features that are less than 10 years?
>
> - 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.
As far as I know, the file is not even used.

>
> - 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?
I would have said this is no real trouble (until now). But it is not important 
to me. Replacing std::shared_ptr by Dune::shared_ptr (or whatever) is a simple 
sed command.

>
> - 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.
Doesn't that only mead Dune::Std is fine with everyone? Or should we actually 
vote on this again?

>
> 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?
Because it is a one-liner (using std::shared_ptr) and allows for compatible 
reimplementation, if std::shared_ptr is buggy.

>
> 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?
As for 3.0: I was kind of surprised that we don't go for 2.4. Maybe my memory 
dropped some decision from Aachen. I agree that the 3.0 release should be 
allowed to break compatibility (especially for C++11). But then, I would also 
say that 3.0 should require gcc-4.6+. I would even suggest not to have 
deprecations this time. If we want more compatibilty, we can have a "stable" 
branch targeting for a 2.4 release (maybe early next year) and the 
non-backward compatible 3.0 "master" branch (whose release can then be delayed 
a little).

>
> 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.
Well, either XLC goes C++11, or we have to break compatiblity eventually. For 
3.0, that would be fine with me.
>
> == tl;dr ==
> (Too long; didn't read)
> I am not happy with our decision and would like to hear your opinion.
If this discussion starts to get lengthy, we should migrate it to FlySpray.

>
> Bye
> Christoph
>
>
>
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-devel
>

Best,

Martin

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany