The approach I have in mind for this library respect to scheduled work of the N3785 proposal is quite different. Instead of adding the scheduled operations to a specific scheduled_executor polymorphic interface, I opted by adding two member template functions to a class scheduled_executor that wraps an existing executor. This scheduled_executor will probably have a thread to take of the time scheduled operations, but this is not necessary. The semantic of the time scheduled operations is a little bit different. The task will be submitted to the associated executor at/after the given time_point/duration.
This describes the scheduling_adaptor class. Since there are no virtual methods the addition of template functions is possible.
Note that your base class scheduled_executor is not an executor at all.
Perhaps I should move this into detail then. I could also change the name to scheduled_executor_base and perhaps then change scheduling_adaptor to scheduled_executor. This however would rule out any possible use of the scheduled_executor class a polymorphic base class since it would be hidden in detail.
This has several advantages: * The time scheduled operations are available for all the executors.
This is provided via the scheduling_adaptor class.
* The template functions could accept any chrono::steady_clock::time_point or any chrono::duration.
I can add template functions to do this. Others have requested this.
* The non-time scheduled task don't pay for the additional cost to manage with a priority queue.
I can override (non-virtually) the submit(work) function in scheduling_adaptor to do this. This however will complicate to ability to use the scheduled_executor polymorphically as calls though scheduling_adaptor will avoid the queue while calls through a scheduled_executor& will put the task at the front/top. Both will have the same behaviour but one will go through the queue. Although it was never my intention of have this polymorphic behaviour it was a nice consequence of my design. Ian,