Ryan_001

Members
  • Content count

    689
  • Joined

  • Last visited

Community Reputation

3462 Excellent

About Ryan_001

  • Rank
    Advanced Member
  1. So I threw together a little test benchmark. On my system (Windows 7, Intel i7) both sleep_for() and Sleep() were identical. When VS (and a few other programs in the background) were open I was getting 1ms accuracy for both (+/- 10us or so). So both performed well. With everything closed though that number jumped up and would vary between 5ms and 15ms; but whatever the number was for sleep_for(), Sleep() was identical. So either VS or some other program in the background was calling timeBeingPeriod(1). It seems either way, under the hood, sleep_for() is identical to Sleep() on Windows 7 with VS 2017.
  2. https://msdn.microsoft.com/en-us/library/hh874757.aspx says: Which is good because QPF is the best timer on a Windows system, is quite stable and has nanosecond precision. If you're curious as to the details this link here: https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx. How exactly sleep_for() and sleep_until() are implemented, I'm not sure. Sleep() we do know uses the internal system clock interrupt, which fires every few milliseconds (7-15ms from what I understand on most systems). Without some benchmarking I can't say for sure, but I'm certain that sleep_for() and sleep_until() will be at least as accurate as Sleep() and possibly better.
  3. I think Hodgman is more talking along the lines of the of the Win32 message loop; GetMessage() and PeekMessage() return an error code/exit code so that the message loop knows when the final 'quit' message has been received. You would either need Delegate() to return an error/exit code, or have a special CheckDelegate()/ExitDelegate() function that returns an error/exit code if the next delegate function is the special 'quit' message. That way the message loops knows when to stop processing messages. If all the delegates have to be executed, perhaps execute just the delegates that are non-destroying first, then all the destroying one? Something like this comes to mind: // returns true if the delegate is an 'exit' message for the given object bool IsExit(const Delegate&, const Signal*); void Signal::operator()() const { for(auto& delegate : delegate_list) { if (!IsExit(delegate, this)) delegate.Call(); } for(auto& delegate : delegate_list) { if (IsExit(delegate, this)) { delegate.Call(); return; } } } Or perhaps something like: void Signal::operator()() const { bool has_exit_signal = false; for(auto& delegate : delegate_list) { if (IsExit(delegate, this)) has_exit_signal = true; else delegate.Call(); } if (has_exit_signal) { // write special code to kill object // delete this; // DestroyObject(this); // depending on how the objects are created/stored would change what goes here... } }
  4. I was going to post basically the exact same thing and agree completely. I also use raw pointers in places where the lifetime management is know and handled by something else. You'll quite commonly find raw pointers in class internals as private members since you know when they are created, when they are accessed, when they are destroyed, and who owns what. When in doubt use a smart pointer. Many others will suggest to always use smart pointers, which isn't a terrible thing, but is more a 'rule of thumb' for beginners than a hard and fast rule.