4

I've noticed two different ways to "pause" in C++. (Though I think the proper name for it is sleeping.)

Method 1, (probably the method most are familiar with):

#include <iostream>
#include <unistd.h>
int main() {
  std::cout<<"Hello, "<<std::endl;
  sleep(1);
  std::cout<<"world!\n";
  return 0;
}

And the method I learned first:

#include <iostream>
#include <thread>
#include <chrono>
int main() {
  std::cout<<"Hello, "<<std::endl;
  std::this_thread::sleep_for(std::chrono::seconds(1));
  std::cout<<"world!\n";
  return 0;
}

I'm not asking which way is right, (they both do the same thing), but rather I'm asking which is more used, or "accepted". Also, is there a difference between these two when it comes to things like speed/performance?

Domani Tomlindo
  • 239
  • 1
  • 5
  • 12
  • 2
    "is there a difference between these two when it comes to things like speed/performance?" - you are suspending execution for an *entire second*. Performance is out the window right there. – Jesper Juhl Oct 30 '18 at 20:55
  • 2
    Best bet is not to pause. There is almost never any need to do it, and it's bad UI design because the user can't skip the pause. –  Oct 30 '18 at 20:55
  • 2
    As long as you don't mind limiting your code base to C++11 or higher `std::this_thread::sleep_for` is 100% portable in that enviroment while `sleep` isn't. – NathanOliver Oct 30 '18 at 20:55
  • @Kamil Cuk: The surrounding `extern` does not hurt, but is not necessary. Most headers enable it by default when `__cplusplus` is defined. – andreee Oct 30 '18 at 20:57
  • 1
    In production code, a sleep frequently indicates that someone had a problem in their code that was avoided by allowing another process a "little more time" to finish what it was doing. A sleep is a red flag which points the developer to investigate why the sleep was helpful in the first place. As @NeilButterworth indicated, there is rarely a good reason for it. – Gardener Oct 30 '18 at 21:01
  • @NeilButterworth "There is almost never any need to do it" Unless when this is exactly what you need, which happens surprisingly often. Sure, freezing interactive UI is bad, but I don't see anyone trying that (the example is not interactive). – Frax Oct 30 '18 at 22:52
  • @Frax Anything that displays output on a screen is interactive. –  Oct 30 '18 at 22:55
  • @NeilButterworth Of course not. _Interactive_ means _allowing a two-way flow of information between a computer and a computer-user; responding to a user’s input_. There is no place for user input or action, therefore this program is not interactive. – Frax Oct 30 '18 at 22:59
  • @Frax Ctrl-C, click the `X` button. These are interactive, but terminate the program (sending signals to it) , but don't skip the pause, which was my original point. –  Oct 30 '18 at 23:03

2 Answers2

8

The difference between these two methods is the portability:

  • sleep from unistd.h is part of the C POSIX Library and therefore only available on Systems that provide the POSIX-API (e.g. Linux, BSD, ...) but for example not on Windows

  • std::this_thread::sleep_for is part of the C++ Standard Library (since C++11) and is therefore available on all platforms that support C++11 and newer

If you have the choice use std::this_thread::sleep_for to rely only on a C++11 implementation and not on the System API.

NathanOliver
  • 171,901
  • 28
  • 288
  • 402
Simon Plasger
  • 116
  • 1
  • 4
  • 1
    I'd add a second difference is granularity. `sleep()` can sleep only for *seconds* -- whole seconds. `std::this_thread::sleep_for()` can potentially get down to *microseconds*. Though there's also `usleep()`, which is also not portable. – Fred Larson Oct 30 '18 at 21:08
3

Primary differences:

  • std::this_thread::sleep_for is a standard function (since C++11). sleep is a POSIX standard function, and so is only available on systems that support POSIX.
  • The unit of the argument of sleep is seconds, while std::this_thread::sleep_for allows the use of any std::chrono::duration (although the clock used for measurement will have its own granlarity that may be less precise than the time that you specify).
  • The behaviour of std::this_thread::sleep_for is not defined in relation to signals that may interrput program flow. Typically, std::this_thread::sleep_for will be interrupted prematurely just like sleep would be, but there is no easy way of finding out how much time was left to sleep. sleep on the other hand returns the time left to sleep, so it is easy to deal with interruptions using a loop that sleeps until returned time to sleep is zero.
eerorika
  • 232,697
  • 12
  • 197
  • 326