No. Sleeping is a platform-specific thing which tells the scheduler to give CPU time to other processes. You cannot simulate this without additional libs.
This is so NOT beginners topic. Sleep() yields whatever time slice is left for the thread and then the OS will re-schedule it but only after the specified time has ellapsed. This means the OS needs to be informed of the chosen time.
So how do you do this? By calling Sleep() from Windows.h!! hehe You just cannot emulate it.
If you just want to sleep for a tiny bit, you should use SwitchToThread(). It will just do the first part of Sleep(), which is most likely what you need.
I'm not sure if this works, but I've been told that if you use a FOR loop with the iterations being 1000 for example, it will effectively sleep for 1000 ms. Once again, this is not confirmed.
What you're suggesting, packetpirate, will hold up the thread of execution but it won't return time back to the processor. In fact, it'll take up a *lot* of compute cycles that way.
I see no problem using Sleep(), usleep(), or a platform-independent (read: macros) equivalent.
It's perfectly safe to use Sleep() to yield as long as your code doesn't assume that between the time Sleep(x) is called and the time it returns, exactly x milliseconds have passed. In reality, the only guarantee you have is that the thread will yield for at least x milliseconds.
webJose: Don't be sarcastic when it's your fault for not making yourself clear.
My programs tend to hog cpu usage, by as much as 50% for a hello world in a while(1) loop or something like that.
Your program needs a lot of processor time (infinite). The planner, in all its benevolence, tries to follow "Ask, and Ye Shall Receive" (actually, he hates you, and wants you to die as soon as possible).
If you don't want to monopolise the resources, "be nice" and lower your priority (and by lower I meant raise it).
However, be aware that your program now will take longer to finish (it is... more infinite)
Personally I stay away from messing up thread priorities as much as possible so as to not imbalance the complex scheduling algorithm of the operating system. But the function is out there so you might as well try it out.
Generally speaking, it's a much worse problem when a program is not using 100% of a CPU. It means it's wasting a lot of time waiting for some I/O device to catch up and it's running much slower than it otherwise could.