Remove the Boost dependency (and make it really header only)

[acki-m]

I evaluated several benchmark libraries for C++.
Right at the moment I could not find one benchmark library which is really header only.
For the next release, I wish you could get rid of the boost dependency and make the library a really header only library.

The test framework Catch is also header only, but does not contain a benchmark functionality.
Your library can fill this part. I also think a lot of users would like to simply add the header and start benching.

PS: what is the reason for the pthread linking on linux? Maybe you can also fix this (with std::thread?)
PPS: I also does not see an explanation for linking against boost::chrono on windows, why is this the case?

[rmartinho]

I personally would like to get rid of boost too, but I decided to stick to it for an initial release because I didn't want to replicate the features from boost that I'm using. I'm making a list of features from boost that I use so that I can gradually replace them. Most of them are just mathematical and statistical functions which I didn't want to reinvent and test. I'm currently working on another reporting feature (kernel density estimate charts), and for that I already had to write my own of several math functions (thanks @Mysticial for the FFTs :D), anyway. Replacing the boost stats stuff is on my table for when I finish the KDE feature.

Regarding your other questions, I should probably be clearer in the docs, I suppose.

PS: what is the reason for the pthread linking on linux?

The analysis step is multi-threaded; that's why you need pthreads on Linux. There are two bootstraps being done, one for average and one for the standard deviation, and they run in separate threads. In some of the machines I used for development the bootstraps took a noticeable amount of time, so I split them off into separate threads to cut the time by half since they're completely independent and CPU-bound processes. I have considered making the use of threads a configurable parameter, though, or maybe just going back to a single thread if users say it's a nuissance.

Maybe you can also fix this (with std::thread?)

I do use std::thread. It just happens that with GCC on Linux you need to pass -pthread for that to work. Ideally, whether I use threads or not in my library should not be observable for the user, but the current state of affairs makes it not so. :(

PPS: I also does not see an explanation for linking against boost::chrono on windows, why is this the case?

The <chrono> header in Visual Studio 2013 has two main problems:

1. It ships clocks that are of very low resolution; this essentially forces every sample to consistent of an much much larger number of runs to compensate for the low resolution, and then collecting a few hundreds of samples ends up taking forever. During development, a benchmarking session that would run in a few seconds with a decent clock took minutes when compiled with Visual Studio's <chrono>.
2. It has bugs in the arithmetic operations.

Boost.Chrono fixes both of these and in Visual Studio it doesn't require any kind of change to compiler flags or anything of the sort, so you only notice you need it if you don't have boost. With Visual Studio 2015, <chrono> has been fixed. @ThePhD sent a PR that makes nonius detect this and use the standard header, so Boost.Chrono will not be needed if you use a newer version of Visual Studio (2015 is now on RC).

[rmartinho]

Depends on #47 and #48

[acki-m]

what is the current state Martinho? I would really get rid of the boost dependency with nonius, at least for linux builds...

[bitshifter]

@acki-m I've created PR's #81 and #85 to remove the boost dependency. They aren't merged yet, but in the mean time if you feel like testing them that would be useful.

[bitshifter]

There is one remaining reference to boost in include/nonius/clock.h++. But this is only used if NONIUS_USE_BOOST_CHRONO is defined or if NONIUS_MSVC version < 1900. I don't think MSVC < 1900 is supported anyway, so perhaps this can be safely removed?