Personally all I would do is change the "timers_local_include.hpp" to <boost/timers/local_include.hpp> (I've done this locally as well).
I'm not quite usre what you meant by that... I don't have an header named "timers_local_include.hpp" at the moment... I guess you mean use <> inclusion rather than "" inclusion, and yes I agree with that. As at the moment the library is more to be used for testing I made it so you don't need to put in in /boost for it to work. What are the requirements on devices? Do they need to be copyable? Do
they need to start stopped? Do they need to be cheap to pass-by-value? etc.
That's something to be defined... There are other questions like should be able to change the timeing device at runtime ? At the moment I focus my efforts on collecting informations the available apis so I know about their portability and I'm writing tests so I can measure their overhead & resolution and categorize them... but it's quite more work than I expected :) Interestingly a typo in my code led me to a timer that used another
timer as its device... funny that timer appears to satisfy the requirements of the TimingDevice concept.
Hehe interesting, there are still open questions about what exactly a timeing device should be (what members it'd provide, what support it'd offer etc). At the moment I'm a bit working too much and I barely have time to work on the library which is a shame. I expect to have more free time in august and I hope I'd be able to submit it around september for a review. Thank you for your input it's really appreciated. Philippe