It is better to let the RunBenchmarks(), report() decide whether to actually *only* output aggregates or not, depending on whether there are actually aggregates. It's subtle indeed. Previously, `BenchmarkRunner()` always said that "if there are no repetitions, then you should never output only the repetitions". And the `report()` simply assumed that the `report_aggregates_only` bool it received makes sense, and simply used it. Now, the logic is the same, but the blame has shifted. `BenchmarkRunner()` always propagates what those benchmarks would have wanted to happen wrt the aggregates. And the `report()` lambda has to actually consider both the `report_aggregates_only` bool, and it's meaningfulness. To put it in the context of the patch series - if the repetition count was `1`, but `*_report_aggregates_only` was set to `true`, and we capture each iteration separately, then we will compute the aggregates, but then output everything, both the iteration, and aggregates, despite `*_report_aggregates_only` being set to `true`.
| Name |
Last commit
|
Last update |
|---|---|---|
| cmake | Loading commit data... | |
| docs | Loading commit data... | |
| include/benchmark | Loading commit data... | |
| src | Loading commit data... | |
| test | Loading commit data... | |
| tools | Loading commit data... | |
| .clang-format | Loading commit data... | |
| .gitignore | Loading commit data... | |
| .travis-libcxx-setup.sh | Loading commit data... | |
| .travis.yml | Loading commit data... | |
| .ycm_extra_conf.py | Loading commit data... | |
| AUTHORS | Loading commit data... | |
| BUILD.bazel | Loading commit data... | |
| CMakeLists.txt | Loading commit data... | |
| CONTRIBUTING.md | Loading commit data... | |
| CONTRIBUTORS | Loading commit data... | |
| LICENSE | Loading commit data... | |
| README.md | Loading commit data... | |
| WORKSPACE | Loading commit data... | |
| appveyor.yml | Loading commit data... | |
| mingw.py | Loading commit data... | |
| releasing.md | Loading commit data... |