From: Philippe Vaucher (philippe.vaucher_at_[hidden])
Date: 2007-07-19 10:53:57
> boost/timers.hpp assumes if you are not on windows you are on a posix
> system. I'm porting to a different platform which is neither windows nor
> posix compatible.
Well what's in the vault is more a draft than anything finished. What's
planed is having a tons of boost::config macros in order to have better
control of the whole thing... like ability to simulate windows 95 mode even
on a windows XP or stuffs like that.
Another idea could be to provide a set of tags representing the apis and
their properties and then some kind of mpl-get_timer() function where you'd
pass the wanted properties and it's return the best one available. Tho it
looks a bit like overengineering.
WIN32_LEAN_AND_MEAN is defined in the windows device headers and then
> windows.h is included. This could lead to issues where depending on
> order of inclusion in a project WIN32_LEAN_AND_MEAN could be either
> defined or undefined when windows.h is included (and this is certainly
> imposing that define on the user).
Oh good point I'll add checks and undefine it after the header if it wasn't
Include guards in all files begin with the reserved underscore capital
> letter combination.
I thought underscores were reserved for compiler implementers & libraries
timeGetTime.hpp links against the winmm.lib and is included through a
> simple #include <boost/timers.hpp> even though I'm not planning to use
> the timeGetTime timer. Might not be a huge deal... I'll probably just
> have to avoid the convenience header and do preprocessor platform
> switching in my own application.
Well that was to follow the dynamic linking already present in other boost
libraries but I'll look if I can kind of make it happen only when you do use
I don't find the everything and the kitchen sink convenience header to
> be very useful for this library. Perhaps providing other convenience
> headers and typedefs for platform independent timers like for instance
> hires_timer, general_purpose_timer, or slow_polling_timer would be
> useful so ugly preprocessor switching logic can be kept out of user
Yeah that's planned as well, make typedefs based on timers usage.
Thank you for your input!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk