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`.
> 
> What is best practice in this case?
> 
> 
> 

The best practice is to delete the move constructor and move assignment operator to prevent this from happening. Your object requires that `this` never changes, and you're getting undefined behavior because in this case the object was whipped out from beneath your thread and subsequently destroyed.

If, for whatever reason preventing moves goes against your design requirements, then there are a some common approaches that would make the most sense to anybody fortunate enough to be reading and maintaining your code.

1. Use the *pimpl idiom* to create an internal object dynamically which can move with the outer object. The outer object is movable, but the inner object is not. The thread is bound to that object, and anything the thread needs access to is also within that object. In your case, you would basically take your structure as it is and wrap it. The basic idea is something like:

```
class MovableA
{
public:
    MovableA() : a_(std::make_unique<A>()) {}
    void start() { a_->start(); }
    A & a() const { return *a_; }
private:
    std::unique_ptr<A> a_;
};

```

The benefit of this approach is that you can move `MoveableA` without needing to synchronize with the running thread.
2. Abandon the notion of using stack allocation, and just allocate `A` dynamically. This has the same benefit as option 1, and is simpler because you're not having to wrap your class in anything or provide accessors.

```
std::unique_ptr<A> m;
{
    auto a = std::make_unique<A>();
    a->v_ = "bar";
    a->start();
    m = std::move(a);
}
std::cout << "v_ = " << m->v_ << '\n';
m->t_.join();

```

I started writing an option 3 that avoids dynamic allocation and instead binds a 'floating' version of `this` to a `std::reference_wrapper` but I felt I'd get it wrong without thinking about it a lot, and it seemed hacky and horrible anyway.

The bottom line is if you want to keep the object outside your thread *and* use it in the thread, the best practice is to use dynamic allocation.