I would like to add that this very much overlaps with executors and
networking and once that lands, if there isn't a timer or a thing that can
serve as one with a thin shim (timers are tricky beasts and
one-size-fits-all is something I have yet to see) then I will be very
surprised.

Thank you for the proposal, and if you want to get involved with the
concurrency subgroup, I'm sure they could use an extra pair of eyes on
their stuff.

G

On Sat, Jan 11, 2020, 16:25 Arthur O'Dwyer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Fri, Jan 10, 2020 at 6:28 PM contact--- via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Hello,
>>
>> I hope you're well and you enjoy 2020. I'm writing you a short message
>> about a C++ proposal. Of course, the C++ is my favorite programming
>> language and I have an idea about a new std class or struct that doesn't
>> yet exist. I think it could be cool to have a std::timer similar to the
>> win32 timer (
>> https://docs.microsoft.com/en-us/windows/win32/winmsg/using-timers) or
>> the qt timer (https://doc.qt.io/qt-5/qtimer.html) or the GLUT timer (
>> https://linux.die.net/man/3/gluttimerfunc) or ...
>>
>> The implementation can be discuted of course. It can use std::chrono,
>> std::thread, std::function and more.
>>
>> This is a draft.
>>
>> namespace std
>> {
>> class timer
>> {
>> public:
>>
>> timer(); // constructor
>>
>> // ANOTHER VERSION OF THE CONSTRUCTORS : THE ADVANCED VERSION with which
>> thread to use for the call of the callback
>> timer(); // will call the callback on the main thread (or
>> the thread where the timer has been constructed)
>> timer(thread_id); // will use this thread_id for the call of
>> the callback
>>
>
> How would you expect this to work? If you provide the thread_id of an
> existing thread, then the timer can't call its callback "on that thread"
> because that thread is already doing its own thing. And if you provide the
> thread_id of a non-existent thread, that doesn't seem useful.
>
> I recommend starting with an *implementation* of the facility that you
> can actually use in your own code, and then, if it proves useful, then
> worry about porting it to other platforms; and finally, if you find that
> you need a standard to iron out unintentional differences between your
> implementations on different platforms, *that's* the time to think about
> standardization.
>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>