unnecessary dependency on boost.date_time when building with separate compilation

[arvid@…]

The time_queue.hpp header file, in addition to defining the template, also defines one instantiation of it using boost::posix_time::ptime as the time type. This instantiation is then implemented in impl/timer_queue.ipp. This definition is only visible when building asio with the separate compilation option.

If a client never uses the date_time ptime type, nor its clock, this results in an unnecessary dependency on boost.date_time (at least on windows, possibly because the gregorian::date_type constructor needs to be resolved at link-time). Simply commenting the extra instantiation solves the problem (i.e. removes the dependency on boost.date_time).

I would suggest simply removing this explicit instantiation of the timer_queue template when building with separate compilation. From what I can tell, that would not cause any serious problems for any other use. Building with headers-only would not be affected at all, and building with separate compilation and actually using the boost::posix_time::ptime time_trait, it would just be instantiated automatically anyway, just like when using headers-only.

I marked this as boost 1.46.0 because that's what I'm testing with on windows., but from what I can tell, this is still a problem in 1.49.0, since timer_queue_ptime.hpp is included in src.hpp

[chris_kohlhoff]

Is that a regression in boost.date_time? I believe it used to work without needing a library for these uses.

The rationale for the timer_queue<ptime> specialisation is to minimise code duplication across object files / shared libraries. Removing it and relying on automatic template instantiation defeats that.

However you can consider asio/impl/src.hpp as simply representing the default case for separate compilation. You can roll your own file that includes a minimal set of .ipp files as needed to resolve link dependencies. In more recent boost versions this would allow you to leave out timer_queue_ptime.ipp altogether.

Note that a future version of asio will allow boost.date_time use to be disabled completely.

[anonymous]

It's not a regression in the sense that separate compilation didn't used be an option. But it is a regression in the sense that switching over to separate compilation changed behavior.

I see your point that I could copy-paste src.hpp and pull out this one file. I'll do this, thanks!

Maybe in the future the default deadline_timer in asio will use chrono even.