From: Alexander C. <Ale...@gm...> - 2010-06-30 13:21:52
|
Hi all, when compiling my app with Mingw it states that "usleep was not declared in this scope". Is it really not available with Mingw or do I have to include further headers ? Since I am currently a little puzzled any hint appreciated. Thanks in advance -- A l e x |
From: Tor L. <tm...@ik...> - 2010-06-30 13:29:30
|
> when compiling my app with Mingw it states that "usleep was not declared in this scope". Is it really not available with Mingw Why would it be? MinGW or not, nope, usleep() is not available on Windows. You can use Sleep(), which takes milliseconds, not microseconds, and the actual granularity offered is even less, but for most purposes it should be fine anyway. --tml |
From: Alexander C. <Ale...@gm...> - 2010-06-30 14:08:46
|
>> when compiling my app with Mingw it states that "usleep was not declared in this scope". Is it really not available with Mingw > > Why would it be? MinGW or not, nope, usleep() is not available on > Windows. You can use Sleep(), which takes milliseconds, not > microseconds, and the actual granularity offered is even less, but > for most purposes it should be fine anyway. Hi Tor, thanks for the swift response. Yes, this is what I am aware of too - just needed confirmation. Nevertheless, I urgently need microsecond resolution. In that context I thought about using select() instead. If anyone has a better idea how to approach this on Windows please let me know. Thanks in advance, regards - A l e x |
From: Jasper H. <jas...@gm...> - 2010-06-30 14:31:31
|
A l e x wrote: > thanks for the swift response. Yes, this is what I am aware of too - just needed confirmation. Nevertheless, I urgently need microsecond resolution. In that context I thought about using select() instead. If anyone has a better idea how to approach this on Windows please let me know. AFAIK Windows simply does not provide microsecond control. Perhaps you can tell us what you need it for, so we can help you think of a way to sure you no longer need it. Jasper Horn |
From: LRN <lr...@gm...> - 2010-06-30 15:06:39
|
On 30.06.2010 18:31, Jasper Horn wrote: > A l e x wrote: >> thanks for the swift response. Yes, this is what I am aware of too - just needed confirmation. Nevertheless, I urgently need microsecond resolution. In that context I thought about using select() instead. If anyone has a better idea how to approach this on Windows please let me know. > AFAIK Windows simply does not provide microsecond control. Perhaps you > can tell us what you need it for, so we can help you think of a way to > sure you no longer need it. > > Jasper Horn > > If you google for sleep-less-than-one-millisecond, you'll find a nice article at Stackoverflow that explains both a socked-based approach with select(), and why it sux in practice. I would also recommend reading "Microsecond timer for Windows" article at decompile.com for some pointers on how to measure time with microsecond precision without going to sleep. |
From: Zouzou <int...@12...> - 2010-06-30 14:32:13
|
> when compiling my app with Mingw it states that "usleep was not declared > in this scope". Is it really not available with Mingw or do I have to > include further headers ? #include <unistd.h> Zouzou |
From: Tor L. <tm...@ik...> - 2010-06-30 14:46:42
|
> #include <unistd.h> Oops, I hadn't noticed libmingwex nowadays indeed has a usleep(). Thanks, zouzou. Still, looking in its source shows that is just does: Sleep((useconds + 999) / 1000); --tml |
From: Alexander C. <Ale...@gm...> - 2010-07-01 07:06:14
|
> Oops, I hadn't noticed libmingwex nowadays indeed has a usleep(). > Thanks, zouzou. Still, looking in its source shows that is just does: > > Sleep((useconds + 999) / 1000); ... yes - the same as it is the case with the nanosleep implementation. So, Sleep indeed takes values below 1, which I didn't expect at all. Nevertheless, I am wondering how accurate this will be. I will go and figure. One last thing: Despite including <unistd.h> it tells me "usleep was not declared in this scope". So far that confuses me. I just installed the latest Mingw but it did not lead to a change. I anyone has a further guess why, please let me know. Thanks -- A l e x |
From: Greg C. <gch...@sb...> - 2010-07-01 09:03:43
|
On 2010-07-01 07:06Z, Alexander Carôt wrote: > > One last thing: Despite including <unistd.h> it tells me > "usleep was not declared in this scope". So far that confuses me. Are you using a makefile that defines '__NO_ISOCEXT'? Is there another 'unistd.h' earlier on the include path? Or an include file that redefines 'usleep'? |
From: Greg C. <gch...@sb...> - 2010-07-01 09:55:22
|
On 2010-07-01 09:25Z, Alexander Carôt wrote: > >> Are you using a makefile that defines '__NO_ISOCEXT'? >> >> Is there another 'unistd.h' earlier on the include path? >> Or an include file that redefines 'usleep'? > > no - neither way. The current project uses Qt and works fine on OSX and Linux. > The Makefile is generated via qmake and does not define __NO_ISOCEXT. Then I'm out of quick ideas. I looked at <unistd.h>, and it seems to declare usleep() as long as that macro is not defined. |
From: Alexander C. <Ale...@gm...> - 2010-07-01 10:37:27
|
> Then I'm out of quick ideas. I looked at <unistd.h>, and it seems to > declare usleep() as long as that macro is not defined. Thanks Tor and Greg -- I will check it asap and will get back. It appears to be a tiny "stupid" problem on my end. Once I have figured I will call. Best -- A l e x |
From: Alexander C. <Ale...@gm...> - 2010-07-05 13:08:11
|
> Thanks Tor and Greg -- I will check it asap and will get back. It appears to be a tiny "stupid" problem on my end. Once I have figured I will call. ... as expected it was just a stupid PATH-problem due to numerous MinGW-versions (one in the default Qt-Dir, one in MSYS and the latest, which contained usleep). Now usleep works fine. Thanks for your help, best -- A l e x |
From: Greg C. <gch...@sb...> - 2010-06-30 14:59:44
|
On 2010-06-30 14:08Z, Alexander Carôt wrote: > > Nevertheless, I urgently need microsecond resolution. Here are nanosleep() implementations with tests and discussion: http://permalink.gmane.org/gmane.comp.lib.gnulib.bugs/21294 |
From: Tor L. <tm...@ik...> - 2010-06-30 15:11:17
|
> Here are nanosleep() implementations with tests and discussion: > http://permalink.gmane.org/gmane.comp.lib.gnulib.bugs/21294 Just a warning/note: The code in that article is GPL, presumably, as it is suggested to go into gnulib. --tml |
From: Tor L. <tm...@ik...> - 2010-07-01 08:18:05
|
>> Sleep((useconds + 999) / 1000); > So, Sleep indeed takes values below 1, I certainly doesn't. (Well, it takes zero.) The argument to it is a DWORD, an unsigned 32-bit integer. (useconds + 999) / 1000 is an integer division which results in an integer result. (And even if it was an expression of type float or double, the prototype for Sleep() means the argument would be converted to a DWORD before calling Sleep() anyway. Perhaps you need to read up on how the C language works.) > Nevertheless, I am wondering how accurate this will be. As that article that was linked to earlier in this thread showed through experimentation, not very accurate. > One last thing: Despite including <unistd.h> it tells me "usleep was not declared in this scope". Is C++ involved? --tml |
From: Alexander C. <Ale...@gm...> - 2010-07-01 08:47:59
|
> Perhaps you need to read up on how the C language > works.) No - really not at all. I am simply terribly involved with other stuff, which is why I appreciate such quick pointers from your side very much. > As that article that was linked to earlier in this thread showed > through experimentation, not very accurate. Well - of course according to my requirements and not in general. Once I have checked that I will report back. >> One last thing: Despite including <unistd.h> it tells me "usleep was not declared in this scope". > > Is C++ involved? Yes, it is. Can you tell what to be done ? Thanks again and best regards -- A l e x |
From: Alexander C. <Ale...@gm...> - 2010-07-01 09:25:20
|
Hi Greg, > Are you using a makefile that defines '__NO_ISOCEXT'? > > Is there another 'unistd.h' earlier on the include path? > Or an include file that redefines 'usleep'? no - neither way. The current project uses Qt and works fine on OSX and Linux. The Makefile is generated via qmake and does not define __NO_ISOCEXT. Porting it to Mingw has been pretty uncomplicated so far -- just this little usleep problem remaining. Tor mentioned C++ involvement earlier. In what sense could that be related ? Best -- A l e x |
From: Tor L. <tm...@ik...> - 2010-07-01 10:30:34
|
> Tor mentioned C++ involvement earlier. In what sense could that be related ? I am not a C++ expert (thank goddess), but namespaces and stuff? Perhaps you need to write ::usleep()? --tml |