Re: [jamboost] windows.h, and requirements

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-06-14 12:58:57

> I've been working with Beman re getting Comeau for Windows in
> good shape with Boost. So first of all, I'd like to thank him
> for his patience, and second of all for his thoughts and guidance
> on issues about Boost.
>
> In the process of going through the regressions, I see that
> in boost\regex\config.hpp that windows.h is used.
> I also note that in boost/regex/user.h there is a paragraph:
>
> // define this to disable Win32 support when available:
> // #define BOOST_REGEX_NO_W32
>
> I'm not clear what the comment means, but in the
> directory I see that there is other code which seems to
> decide whether windows.h is used and? whether is should
> be turned off or not, even on a Windows platform.
>
> Some questions:

I can't answer all of them, but I can provide some info on some.

> 1) Is this the only place windows.h is used?

No.

> 2) Why is it used?

For regex, I have no idea. For Boost.Threads, it's used to get access to
the threading support on Windows.

> 3) What are the implications of turning it off on a Windows platform?
> What "services" are necessary, and if windows.h is not used,
> where are said services expected to come from on a Windows platform?

For Boost.Threads the services are the threading libraries for the OS. I
don't know how else to access these libraries with out windows.h.

> 4) When not on Windows, windows.h is obviously not used.
> What other things are used instead? (I don't necessarily
> raise this as a problem, but to try to get a better view
> of what's going on underneath the build process).

For Boost.Threads, the pthreads.h on POSIX and the Mac Carbon stuff on Macs.

> On the other hand though, an argument could be made that
> boost should not use non-standard OS things. I realize
> though that that had its own quandaries, since then maybe
> that component wouldn't be able to exist at all.

Precisely true for Boost.Threads.

> Am I just misunderstanding, or have things just reached a
> practical wall? I will assume for now I am misunderstanding,
> because, I would expect this to be an non-issue with the
> compilers. And it would seem to me that the code would
> work on non-Windows platforms too (although I realize it
> may add say UNIX dependencies in for the case of UNIX, etc...
> does it?)

Yes.

-- 
William E. Kempf