select [LWN.net]

select

Posted Nov 20, 2008 7:31 UTC (Thu) by ncm (guest, #165)
Parent article: MinGW and why Linux users should care

Am I correct in thinking MinGW doesn't have select()? Or does it, like Win32, have one, but it only works with sockets?

select

Posted Nov 20, 2008 8:04 UTC (Thu) by rwmj (subscriber, #5474) [Link] (5 responses)

"MinGW" neither has nor doesn't have select().

The Fedora MinGW project is a cross-compiler that creates Windows executables. If you want
select-like ability, you could use some Win32 API for that such as - as nix says -
WaitForMultipleObjects.

But you could also (and we'd recommend) use some portability library like glib or NSPR which deals
with the matter in another way and has already been ported to whatever Win32 APIs exist (on
Windows) or whatever Linux/POSIX APIs exist on Linux/Unix.

select

Posted Nov 20, 2008 12:23 UTC (Thu) by aleXXX (subscriber, #2742) [Link] (4 responses)

...or QtCore if the license (GPL or commercial) is ok for you.

Doesn't Boost also have some file/threading classes in the meantime ?
Also signals..

Alex

select

Posted Nov 20, 2008 13:46 UTC (Thu) by rwmj (subscriber, #5474) [Link] (3 responses)

I packaged boost. Boost is a classic example of an upstream package where they've gone off and written their own build system, so they have to maintain all the complexity of building on every system out there, and I had to add to that complexity for cross-compiling. I also did another C++ network environment called POCO, and they also wrote their own build system, completely different from the boost one obviously.

C++ programmers, eh - haven't they suffered enough already?

While we're on the subject of portability libraries, APR (Apache Portable Runtime) is another contender.

Rich.

select

Posted Nov 20, 2008 22:50 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

Cross-compiling and Boost.Jam? You have a stronger soul than I. Just
changing CFLAGS and the preferred installation prefix was hell, and then I
had to figure out why jam coredumped as soon as it started... Autoconf
may be nasty but it's a lot kinder to packagers/builders than bloody jam.
While KDE was searching for a new build system for KDE4 I was in terror
that they'd choose Boost.Jam because it was used for a successful C++
project. Thankfully they are not utterly insane and chose something nicer
(now with added lowercase! ;)))) )

select

Posted Nov 21, 2008 8:50 UTC (Fri) by aleXXX (subscriber, #2742) [Link] (1 responses)

Initial support for building Boost using CMake has been committed to the
Boost repository a few weeks ago.

Alex

select

Posted Nov 22, 2008 12:34 UTC (Sat) by nix (subscriber, #2304) [Link]

That's the best news I've had all week :)

select

Posted Nov 20, 2008 9:52 UTC (Thu) by danpb (subscriber, #4831) [Link]

MinGW at its core is just a cross compiler / toolchain, so it doesn't attempt to make Windows look like POSIX. It provides header files & linker stubs for the Win32 APIs. So you are developing against Win32 APIs, rather than POSIX.

If you want a Windows based runtime environment that strives to completely simulate POSIX APIs, then Cygwin is likely a more suitable choice. If you are happy to work against the Win32 APIs more directly, then GNULib provides wrappers around a number of Win32 APIs to give you a degree of POSIX compatability often good enough for many apps. Finally there are higher level APIs like GLib, QT, NSPR which attempt to provide a platform agnostic APIs.