Moving to C++11 (again)


#1

It seems as if Allen has confirmed that stanc can now be built with optimization, which reduces the size on disk considerably.

There is some question as to whether Python can specify -std=c++0x when using g+±4.6 and -std=c++11 when using g+±4.9. This can be done with R via an environmental variable since users of R 3.2.x are still on g+±4.6 while users of R 3.3.x are on g+±4.9. So, it seems as if we were to require C++11 for Stan, we would be limited to the C++11 features that were incompletely supported by g+±4.6 until April at least when R 3.4.x will be released, R 3.3.x will be considered stable, and R 3.2.x will be considered old stable. So, there is the question of whether there is enough in g+±4.6 to make it worthwhile

http://en.cppreference.com/w/cpp/compiler_support

If we were to require C++11, it would cutoff anyone using g+±4.5 or lower, which is only prevalent on older Linux servers. Of course, at the moment g+±4.4 does not work even without C++11 due to things not being defined in the std library

./stan/math/rev/mat/functor/cvodes_utils.hpp:26: error: ‘runtime_error’ is not a member of ‘std’
./stan/math/prim/mat/fun/round.hpp:19: error: ‘std::round’ has not been declared

but we might be able to work around those.

Ben


#2

When would it be reasonable to sunset support for g++ 4.6 (and R 3.2)?
Could we perhaps just wait several months?


#3

April at the earliest. But what is the part of the C++11 standard that someone wants to utilize that is not implemented in g+±4.6?


#4

Is it currently possible to use C++11 features in new Stan or stan/math C++ code if they’re in g++4.6?


#5

Not yet, but I think we’re getting close. Yet another
reason to not do an in-memory integration with the interfaces,
as those are what’s holding us back.

  • Bob

#6

The interfaces aren’t holding us back. The rstanarm binaries are compiled with C++11 on Windows to get around a Boost warning about long long or something. Allan keeps saying that it is fine on Python.


#7

Is there anything else holding us back from using C++11?

What compilers and features are we restricted to? Or I should
say, which features eliminate which compilers/OS-es/interface
builds?

I’d want to discuss this at the meeting this week, but I’m
not going to be able to make it after all.

  • Bob

#8

Nothing has changed since the last time we talked about it at a Stan meeting. There are a lot of people who still use R 3.2.x on Windows, in which case the least common denominator is the parts of the (future) C++11 standard that g+±4.6.3 implemented with -std=c++0x, which is most everything

http://en.cppreference.com/w/cpp/compiler_support

except alignas, delegating constructors, extended friend declarations, inheriting constructors, user-defined literals, template aliases, override / final, attributes, ref-qualifiers, non-static data member initializers. Also, I don’t think the random or the regex C++11 libraries were implemented by g++ then. Finally, decltype and thread-local storage were incompletely implemented as of g+±4.6.3.

The people who would be hurt most are those on old Linux servers whose support contract limits them to g+±4.5 or lower.


#9

Is it ok to use C++11 for testing? I think it’d help us out a lot.

Regarding g+±4.6.3, I don’t believe for a second what any website says. We’ve been burned by compiler bugs in the past – I’m not so sure I’m ready to hunt down bugs in a g+±4.6.3 pre release version that’s been fixed. I’d rather spend the time trying to get a more up-to-date version of g++ installed on Windows XP, 7, 10 instead.


#10

We’ve had g+±4.9 installed on Windows for months.


#11

Yes, that’s a statement and I know that’s true. It doesn’t answer the
questions I’ve asked. Want to clarify? Here are more questions I have (just
cause I think I understand what you mean by that statement, but it’ll
illuminate what I’m worried about):

  • do the compilers act differently when compiling C++11 vs C++03 enough
    where we might miss a something by testing with C++11?
  • do we need to reinstall g+±4.6.3-prerelease in order to catch compiler
    incompatibilities with C++11?
  • what percentage of Windows RStan users do you think is on g+±4.6.3?
  • what number of Windows RStan users do you think is on g+±4.6.3?
  • do you think it’s possible that we can get most of the g+±4.6.3 users on
    g+±4.9?
  • what do we need to do to educate RStan Windows users for that to happen?

#12

yes

Already installed

33%

10000

no

Have them read the wiki. It is not as if people have had more difficulty with R 3.3.x and RTools33, but some people don’t upgrade and some people aren’t allowed to.


#13

Thanks! So I guess the answer to “can we move to C+±11?” is no? Or only up to what g+±4.6.3-prerelease allows?


#14

That is what I keep saying.


#15

=). I don’t think I ever understood your responses to mean exactly that.

And since you’re agreeing to my last set of questions, mind writing out what you actually mean so I don’t accidentally misinterpret what you’re saying?

And here’s the important part: if we’re able to go to part of the C++11 spec:

  1. what do we need to do build?
  2. how to we ensure these things are still compilable under our limitations?
  • RStan
  • CmdStan
  • Stan
  • Math

#16

I wrote it in the OP:

and again later in the thread

If we call g+±4.6 the least common denominator for C++11, then we would be abandoning Stan on some Linux servers that only have older g++. We would have to test Math and Stan with the least common denominator compiler on the Windows machine in my office, in addition to whatever compilers Travis is using that day. And we would need to test Math and Stan with g+±4.9 on Windows.

The interfaces would need to be tested with various compilers, but probably just before a release rather than every PR. It is very unlikely that anyone using Julia/Matlab/Mathematica/Stata/CmdStan would have the least common denominator compiler. PyStan (I believe) needs the same compiler that was used to build Python, which in the case of C++11 and Windows would by Visual Studio Something that Allen knows. RStan is the same way in that it needs the same compiler that was used to build that version of R, which is different for 3.2.x and 3.3.x.


#17

As far as PyStan is concerned, we can move to C++11. There are some
platforms that use g++ 4.6 but they will very soon not have a supported
version of Python, so not supporting them going forward seems fine.
Windows is only supported in cases where C++11 is supported, so there
are no worries there either.


#18

@bgoodri: I didn’t take this chunk of text to mean “we can move to C+±11 that g+±4.6.3 supports.” If that’s what you meant, sorry – it took another 15 posts for me to understand that’s what you meant. It would help me (and I suspect some of the others) if you were able to summarize what you meant.

In your last post, you said this:

What’s your suggestion? Do you want to abandon users with the older g++? What you wrote was a statement and I don’t know what decision you want or are suggesting based on your statement.

What should we be doing?


#19

We (Ben, Aki, Rob, Daniel, Mike, Jonah) discussed this at the meeting today.

We concluded that starting in April 2017, we could require a C++ compiler that supports C++14. In particular, the minimum g++ version we could require is 4.9. XCode’s default clang++ version supports more of the C++14 standard than g++ 4.9, so we’re ok with Mac.

The reasoning is:

  • R will release 3.4 in April. Starting with version 3.3, RTools has been using g++ 4.9. In April, R will no longer support 3.2, the last version that used 4.6.3.
  • C++11 vs C++14: there is no compiler that defaults to C++11, but g++ 5 and higher defaults to C++14. g++ 4.9 supports most of C++14.

The limiting factor will be PyStan. We may be limited to what portions of the standard MSVC supports.


Compilers / C++11 only or C++11 and C++14?
#20

+1