C++14 has some support. Missing are Variable templates, Extended
constexpr, NSDMIs for aggregates, Avoiding/fusing allocations,
[[deprecated]] attributes.
C++17 (proposed) has minimal support, only Removing trigraphs,
await/resume.
I hope the unsupported C++14 features aren’t features you were planning
on using. I don’t think Python on Windows is going to shift away from
Visual Studio 2015 for some time.
Are there Python users using MSVC versions earlier than 2015?
MSVC 2015 is listed as only missing SFINAE for expressions. I think we can live without that if no code we import from Boost or Eigen uses it. No idea how many compiler headaches we’ll have of the kind we keep running into on Windows (not enough memory, bombing linkers, different sizes and features than clang++ and g++, etc.)
These are stats from RStudio’s servers? How easy is it for pre-3.2 users to get to that server? I didn’t trust the “0-cloud” option for the longest time because I didn’t know where that went.
@Bob_Carpenter will also add Eigen 3.3 to math tonight and tomorrow we’ll play around with compiling it against C++11. The hope is that the move semantics will kick in and we’ll see some significant performance boosts.
Other immediate fixes that we can implement include
Using static_assert to give informative error messages to our template meta programs.
Use auto and decltype to clean up the densities, although we may want to wait for operations and partials to be rewritten so we only have to update each density once.
Implementing some metaprograms as constexpr .
Implementing some metaprograms as variadic template functions.
Use delegating constructors to reduce code duplication or auxiliary init functions.
Use in class member initializers to simplify constructors.
Longer term goals include
Multithreading chains.
Generalizing functors to use std::function and the possibility of closures for some of our functionals.
I think that was most of it – please add new items if I forgot anything.
Still working on that. It busted LLT for forward-mode. I’m making sure that’s the only problem before trying to dive in and fix it. I think it is having mixed type issues in the internals. Also, I’d like to add:
using bind and lambdas to create test functors
using std::function for the arguments to functionals
We definitely want to use those initializers and delgating constructors everywhere. As we discussed at the C++11 meeting today, I don’t know if that’s better to stage by module (like mcmc) or by type of change. I think we don’t have to really decide—we’ll just keep doing these things until we hit a fixed point.
I think pretty much everything is going to be useful!
We have our refactoring work cut out for us. Soooo much is
going to be able to be simplified with this.
OK, 11 PM and I think I have all the tests working for Eigen 3.3.3 with all the g++ versions past 4.9 we’ve been having trouble with. Pull request coming as soon as test-headers passes. I lost all the doc for fvar I added with the last pull req. I’ll bring that in later rather than fussing with it now.
Last hurdle was calling gcc rather than g++, which works fine until you get to the linker.
@wds15 brought up the issue of whether we’d go past g++ 4.8 support, which is apparently what they have on clusters. No idea how common that is elsewhere. He mentioned that it covers all of C++11 but not all of C++14. No idea how it compares to MSVC.
The other thing I was mentioning in the meeting was std::vector::emplace_back. It combines push_back and construction and is the way to add new members to a vector.
It is certainly safe on a branch. I think there is an open question of whether we should do a small release now-ish to fix the problems with the messages not being displayed when the chains cannot be initialized, the chain numbers not appearing in the output, etc. If so, we should do that before putting any C++11/14 stuff in.
@bgoodri: That sounds like a good idea. Let’s do a patch release first. There are a bunch of bugs we can probably knock off in the next couple weeks and some behavior like transformed data RNG inits we can sort out.