cpp11 Syndicate content

warning: Creating default object from empty value in /www/htdocs/w0065fc9/milianw/modules/taxonomy/taxonomy.pages.inc on line 33.

» Maxwell distribution in C++11

Tue, 07/29/2014 - 11:51

Hey all,

I recently needed to generate values following a Maxwell distribution. Wikipedia gives the hint that this is a Gamma distribution, which in C++11 is easily useable. Thus, thanks to <random>, we can setup a Maxwell distribution in a few lines of code:

  1. #include <random>
  2. #include <chrono>
  3. #include <iostream>
  5. using namespace std;
  7. int main()
  8. {
  9. unsigned seed = chrono::system_clock::now().time_since_epoch().count();
  10. default_random_engine generator(seed);
  12. // Boltzmann factor times temperature
  13. const double k_T = 0.1;
  15. // setup the Maxwell distribution, i.e. gamma distribution with alpha = 3/2
  16. gamma_distribution<double> maxwell(3./2., k_T);
  18. // generate Maxwell-distributed values
  19. for (int i = 0; i < 10000; ++i) {
  20. cout << maxwell(generator) << endl;
  21. }
  23. return 0;
  24. }

Pretty neat, I have to say!

» C++11 platform support?

Sun, 11/25/2012 - 17:53

Hello all!

I’m investigating the feasibility of allowing a subset of C++11 in the KDevelop code base, starting after the branch of 4.5 in a few weeks. I do not want to blindly start going that route just to realize afterwards that I’ve alienated a large portion of our user base. Thus I’d very much welcome if you could read through this blog post and give some feedback which we can build our decision on top.

Here’s the email I sent to the KDevelop development mailing list:

Is anyone opposed to open KDevelop 4.6 for C++11? I.e. that means we continue to work as-is and provide a kick-ass KDevelop 4.5. Once we branch 4.5, we enable C++11 mode globally and start using it in master.

  • KDevelop is a free time project and it should be fun to work on it. C++11 is quite a lot of fun, if not only because it’s new. This is actually the main reason for me to go down the C++11 route. This would also allow us to learn C+11 which is a benefit for those of us who do professional work-work programming.

  • Tons of potential performance benefits thanks to constexpr, noexcept, r- value references etc. pp.

  • Much easier to read code thanks to auto, lambdas, alias templates, defaulted functions, etc. pp. This also leads to better maintainability.

  • Improved compiler analysis thanks to e.g. static assert, override, final, nullptr, explicit conversion operators, deleted functions, etc. pp.


See also: http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport

Personally I’d say we should just require these compiler versions and above:

clang 3.1 - required for constexpr, lambda, initializer lists, …

GCC 4.7 - 4.6 might even be enough, but 4.7 has some more stuff like delegating constructors, override, final and non-static data member initialization.

msvc ctp november 2012 (http://blogs.msdn.com/b/vcblog/archive/2012/11/02/visual-c-c-11-and-the-…)

Potential Issues:
  • FreeBSD situation? http://wiki.freebsd.org/NewC%2B%2BStack <— I’m not sure how far they are. But quite frankly, I’d say they can stick to KDevelop 4.5 until they have a modern compiler like clang 3.1.

  • Debian? Wheezy should come with GCC 4.7 if I’m not mistaken: http://packages.debian.org/wheezy/gcc Imo it’s fine if we only support that version of Debian. All other distros probably already have GCC 4.7 available, or will have it in their next distro release in time for KDevelop 4.6

  • Windows? If anything breaks on MSVC it’s imo not an issue as KDevelop is defacto dead on Windows (noone is working on it there). Also considering that the windows team is actually working on proper C++11 support (see link above) its only a matter of time until it has everything we need.

  • Backporting: Now this is imo a potential issue, but considering that we don’t do such a good job in that regard anyways, it’s not that big a deal… And most of the fixes we do backport are oneliners which could be done in the 4.5 branches and forward ported to 4.6.

More Issues

So far a few more concerns where raised:

  • Mac OSX: only “recent” Mac OSX come with a clang that is new enough. Question is: Which version is that exactly? Do people use KDevelop on an older Mac OS? My personal impression was that most Mac users upgrade asap to the newest OS version, thus this should not be an issue?

  • Windows: While the team around Herb Sutter is doing a tremendous job in advancing the compiler to provide kick-ass standard support, apparently the Windows users are reluctant to upgrade… But the obvious question is: Should we be held back by an imaginary Windows user base? KDevelop does compile on Windows, and mostly works but afaik there are still some very sore spots, esp. in the CMake project management and the lack of a MSVC debugger integration. Anyhow, would allowing C++11 in the KDevelop code base make it considerably harder for potential contributors? Considering that even now we do not get any contributions from Windows users, I doubt it can get any worse… But I do see that it’s a hen/egg problem.

  • BSD: FreeBSD is in the process of using Clang. But is that process already finished? If not, is there any ETA? Will there be Clang 3.1? What about other BSDs and Unixoids?

What about unsupported platforms?

Personally, I think KDevelop is currently in a pretty good shape. If some platforms would have to stick to KDevelop 4.5, I don’t see such a big issue in that. We could also think about making it our first “LTS” release and backport essential bug fixes for a longer period.

Why not the Qt way?

Qt 5 makes use of C++11 features where possible in a backwards compatible way. It is of course the correct choice for a library that wants to support multiple platforms. But imo, KDevelop does not have such strict requirements. Rather, it should offer maintainable code that is fun to work on. Thus I am stricly against introducing Q_DECL_CONSTEXPR in our code, instead of using constexpr directly. And of course, in Qt you cannot use auto, nor lambdas, nor many other things as you always have to provide a C++03 fallback.

Lets try it out, no?

As Aleix pointed out, I’ll probably just start a new branch and introduce some C++11 features there. Then we can see whether the gain in code readability or performance is worth the introduction of the mandatory C++11 requirement.