Question: I have to run a command every day at a different time. The times are known in advance and saved in a MySQL database in the familiar `YYYY-MM-DD HH:MM:SS` format.

**What I thought of:**

1. `cron` schedule the job for the exact time the first day, then make the script itself modify the `crontab` entry with the correct time for the next day.
2. `cron` scheduling the job at *approximately* the right time, then make it read the *exact* time from the database and sleep until then.
3. `cron` schedule the job execution every minute, and leave it to the script to determine whether the current date/time corresponds to the right execution time; proceded if it is, exit if not.
4. `at` submit the job the first day with `at`, then make it read the next day's time from the database and resubmit itself for then with `at`.

**Additional info:**

The command is a PHP script that composes the message of the day and sends it to all users registered to the website. I can consider other technologies if they solve this problem better. I would like to retain the ability of rebooting the server (outside of the intended execution hour) without worrying too much about jobs getting lost, therefore solutions `1.` and `3.` look better under this aspect. I'm starting with two commands to be run at two different times of the day, but I could soon end up with dozens more of similar jobs to be scheduled at different times every day, so I would prefer to avoid clutter as much as possible. I'd probably go with option `3` at this point.

**The question(s):**
Is there a better / preferred / established way of accomplishing this task? Solutions other that those mentioned above are welcome. What are the main drawbacks (of your recommended solution) I should be aware of?

Answer: 
As written, it's not going to work. After moving, the thread `m.t_` refers to a thread which is still running `a.threadProc()`. That will be attempting to print `a.v_`. 

There are even two problems with the snippet: not only is `a.v_` moved from (so its value is unspecified), but it's also about to be destroyed in another thread, and that destruction is not sequenced-after its use.

Since the object needs to stay alive long enough, with a non-trivial lifetime due to the thread, you'll need to get it off the stack and out of the vector. Instead, use `std::shared_ptr` to manage the lifetime. You will probably need to pass that `shared_ptr` to the thread, to avoid a race condition where the object might expire before the thread starts running. You can't rely on `std:shared_from_this`.
(Alternative answer, using C++17) 

Using lambda's, you can capture a copy of `A`. Since the thread owns the lambda and the lambda owns the copy, you don't have lifetime issues:

```
t_ = std::thread([*this](){threadProc();});

```