MinGW - Minimalist GNU for Windows

> 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

>> 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

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

> 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

> #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

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

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.

> 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

> 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

>>    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

> 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

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'?

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

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.

> 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

> 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

> 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