From: NightStrike <nig...@gm...> - 2008-01-30 04:37:42
|
Is it required that every program #include <windows.h> before using most of the mingw headers? |
From: Brandon S. <br...@oq...> - 2008-01-30 06:35:13
|
On Jan 29, 2008, at 8:37 PM, NightStrike wrote: > Is it required that every program #include <windows.h> before using > most of the mingw headers? > Not required specifically, but most other headers won't build and would generate a good deal of "unknown <something>". You can define WIN32_LEAN_AND_MEAN to strip out a good deal excluding the basics. Brandon Sneed |
From: Greg C. <gch...@sb...> - 2008-01-30 06:51:55
|
On 2008-01-30 04:37Z, NightStrike wrote: > Is it required that every program #include <windows.h> before using > most of the mingw headers? For many headers like <math.h>, it doesn't matter. But for msw-api headers it's common advice to include <windows.h> first. Try googling for "include windows.h before" (including the double quotes) and you'll see that this advice isn't specific to MinGW. You could well ask why headers that depend on <windows.h> don't just include it themselves. In the early days of msw, that would have been expensive, and preprocessors weren't smart enough to avoid including the same file twice. These days, I guess people have learned how to avoid the issue, so the workaround persists and there isn't much demand to change things. |
From: Vincent T. <vt...@un...> - 2008-01-30 08:49:33
|
On Tue, 29 Jan 2008, NightStrike wrote: > Is it required that every program #include <windows.h> before using > most of the mingw headers? Not always. See msdn. For example, when using sockets, you lay just need winsock2.h Vincent Torri |
From: Tor L. <tm...@ik...> - 2008-01-30 09:10:14
|
> > Is it required that every program #include <windows.h> before using > > most of the mingw headers? > Not always. See msdn. For example, when using sockets, you lay just need > winsock2.h And of course, programs that use just standard C library functions have no need at all to include <windows.h>. They just need <stdio.h>, <stdlib.h>, etc, like on any C89 platform. --tml |
From: Earnie B. <ea...@us...> - 2008-01-30 12:30:26
|
Quoting Tor Lillqvist <tm...@ik...>: >> > Is it required that every program #include <windows.h> before using >> > most of the mingw headers? > >> Not always. See msdn. For example, when using sockets, you lay just need >> winsock2.h > > And of course, programs that use just standard C library functions > have no need at all to include <windows.h>. They just need <stdio.h>, > <stdlib.h>, etc, like on any C89 platform. > Oh, you make me need to change my rule. ;D Earnie |
From: Dave K. <dav...@ar...> - 2008-01-30 10:18:16
|
On 30 January 2008 08:49, Vincent Torri wrote: > On Tue, 29 Jan 2008, NightStrike wrote: > >> Is it required that every program #include <windows.h> before using >> most of the mingw headers? > > Not always. See msdn. For example, when using sockets, you lay just need > winsock2.h > Well, that's because winsock2.h #includes windows.h anyway, pretty much first thing it does. cheers, DaveK -- Can't think of a witty .sigline today.... |
From: NightStrike <nig...@gm...> - 2008-02-02 15:37:23
|
On 1/30/08, Dave Korn <dav...@ar...> wrote: > On 30 January 2008 08:49, Vincent Torri wrote: > > > On Tue, 29 Jan 2008, NightStrike wrote: > > > >> Is it required that every program #include <windows.h> before using > >> most of the mingw headers? > > > > Not always. See msdn. For example, when using sockets, you lay just need > > winsock2.h > > > > Well, that's because winsock2.h #includes windows.h anyway, pretty much > first thing it does. winsock2 does, but many headers that depend on windows.h do not themselves include it. Why does winsock include windows.h but others do not? I would think that a user should only include windows.h if his own code requires it, not if a library he is using requires it. That library should handle its own dependencies, yes? |
From: Keith M. <kei...@us...> - 2008-02-02 16:42:54
|
On Saturday 02 February 2008 15:37, NightStrike wrote: > I would think that a user should only include windows.h if > his own code requires it, not if a library he is using requires it. > That library should handle its own dependencies, yes? Yes. What possible benefit can be gained from #including *any* header, if your compilation unit has no direct dependency on it? This isn't peculiar to windows.h; it applies equally to every header. Regards, Keith. |
From: NightStrike <nig...@gm...> - 2008-02-02 16:49:54
|
On 2/2/08, Keith Marshall <kei...@us...> wrote: > On Saturday 02 February 2008 15:37, NightStrike wrote: > > I would think that a user should only include windows.h if > > his own code requires it, not if a library he is using requires it. > > That library should handle its own dependencies, yes? > > Yes. What possible benefit can be gained from #including *any* header, > if your compilation unit has no direct dependency on it? > > This isn't peculiar to windows.h; it applies equally to every header. It applies to windows.h in so far as that I tried individually compiling every header in mingw with something like this in a script where $file is each .h header: #include <$file> int main() {return 0;} The number of errors drops considerably when I change it to: #include <windows.h> #include <$file> int main() {return 0;} So basically, a number of mingw headers won't compile unless windows.h is also included. If those headers require windows.h, I would think that they should include it themselves. I am assuming that I am misunderstanding something here that everyone sees very clearly. Could you enlighten me? |
From: Tor L. <tm...@ik...> - 2008-02-03 09:24:05
|
> I tried individually compiling every header in mingw with something like > this in a script where $file is each .h header: > > #include <$file> int main() {return 0;} That is rather pointless as many of the headers (especially the win*.h ones immediately come to mind) are specifically intended not to be included directly, but are included by windows.h. Is this how you approach programming in general? Just randomly try things without looking at recommended practice or code samples. I very much doubt you will find any sample code that would include files like wingdi.h directly. > So basically, a number of mingw headers won't compile unless windows.h > is also included. The same presumably holds for the original versions of those headers, from the Microsoft SDKs. As mingw is intended to be a replacement for the Microsoft tools, it wouldn't help portability of code from Microsoft tools to mingw *and* back if mingw started enabling coding practises that the Microsoft SDKs don't allow, and that no code samples and tutorials use. All the above just IMHO, of course. --tml |
From: NightStrike <nig...@gm...> - 2008-02-03 13:08:47
|
On 2/3/08, Tor Lillqvist <tm...@ik...> wrote: > Is this how you approach programming in general? Just randomly try > things without looking at recommended practice or code samples. I very Yet another reason why of all the mailing lists I'm on, this one is the absolute worst...... > All the above just IMHO, of course. Yes, humble indeed. Did you humbly read the rest of the thread, or humbly ignore it? |
From: Roumen P. <bug...@ro...> - 2008-02-03 15:27:50
|
NightStrike wrote: > On 2/3/08, Tor Lillqvist <tm...@ik...> wrote: > >> Is this how you approach programming in general? Just randomly try >> things without looking at recommended practice or code samples. I very >> > > Yet another reason why of all the mailing lists I'm on, this one is > the absolute worst...... > > >> All the above just IMHO, of course. >> > > Yes, humble indeed. Did you humbly read the rest of the thread, or > humbly ignore it? > As is pointed before a program may include other header first that include windows.h. For sockets in particular it is winsock2.h or ws2tcpip.h for winsock 2. If program include windows.h first the result is winsock 1.1. Mingw w32api must not resolve this. Roumen |
From: NightStrike <nig...@gm...> - 2008-02-03 15:47:27
|
On 2/3/08, Roumen Petrov <bug...@ro...> wrote: > As is pointed before a program may include other header first that > include windows.h. Every header should be protected against multiple inclusion. If it's not, that's a bug. The point is that dependencies of a header should be resolved by the header, and not the user of the header. > For sockets in particular it is winsock2.h or ws2tcpip.h for winsock 2. > If program include windows.h first the result is winsock 1.1. > Mingw w32api must not resolve this. #if defined(__USE_W32_SOCKETS) || !(defined(__CYGWIN__) || defined(__MSYS__) || defined(_UWIN)) #if (_WIN32_WINNT >= 0x0400) #include <winsock2.h> /* * MS likes to include mswsock.h here as well, * but that can cause undefined symbols if * winsock2.h is included before windows.h */ #else #include <winsock.h> #endif /* (_WIN32_WINNT >= 0x0400) */ Looks like the default is based on the proper criteria, and not a blanket "include windows.h, get winsock 1" |
From: Keith M. <kei...@us...> - 2008-02-03 16:14:58
|
On Sunday 03 February 2008 15:47, NightStrike wrote: > Every header should be protected against multiple inclusion. =A0If it's > not, that's a bug. Technically, yes. However, I consider it to be just as much a bug to=20 introduce a circular dependency between headers, and subsequently rely=20 on multiple inclusion guards to pull you out of the mire. > The point is that dependencies of a header should=20 > be resolved by the header, and not the user of the header. This doesn't apply, if the user is using a header improperly. When the=20 documentation says `defined in foo.h; include windows.h', then it is a=20 *user* error to `#include <foo.h>'; in this case, foo.h should *not*=20 `#include <windows.h>', to circumvent such misuse. Regards, Keith. |
From: Roumen P. <bug...@ro...> - 2008-02-03 16:37:53
|
NightStrike wrote: > On 2/3/08, Roumen Petrov <bug...@ro...> wrote: > >> As is pointed before a program may include other header first that >> include windows.h. >> > > Every header should be protected against multiple inclusion. If it's > not, that's a bug. The point is that dependencies of a header should > be resolved by the header, and not the user of the header. > > >> For sockets in particular it is winsock2.h or ws2tcpip.h for winsock 2. >> If program include windows.h first the result is winsock 1.1. >> Mingw w32api must not resolve this. >> > > #if defined(__USE_W32_SOCKETS) || !(defined(__CYGWIN__) || > defined(__MSYS__) || defined(_UWIN)) > > #if (_WIN32_WINNT >= 0x0400) > #include <winsock2.h> > /* > * MS likes to include mswsock.h here as well, > * but that can cause undefined symbols if > * winsock2.h is included before windows.h > */ > #else > #include <winsock.h> > #endif /* (_WIN32_WINNT >= 0x0400) */ > > > Looks like the default is based on the proper criteria, and not a > blanket "include windows.h, get winsock 1" > The /Winsock2.h/ header file internally includes core elements from the /Windows.h/ header file, so there is not usually an #include line for the /Windows.h/ header file in Winsock applications. If an #include line is needed for the /Windows.h/ header file, this should be preceded with the #define WIN32_LEAN_AND_MEAN macro. For historical reasons, the /Windows.h/ header defaults to including the /Winsock.h/ header file for Windows Sockets 1.1. The declarations in the /Winsock.h/ header file will conflict with the declarations in the /Winsock2.h/ header file required by Windows Sockets 2.0. The WIN32_LEAN_AND_MEAN macro prevents the /Winsock.h/ from being included by the /Windows.h/ header. $ cat test.h /* #define WIN32_LEAN_AND_MEAN */ #include <windows.h> #include <winsock2.h> $ .../bin/i386-mingw32msvc-gcc -E test.h | grep winsock # 1 ".../i386-mingw32msvc/include/winsock2.h" 1 3 # 17 ".../i386-mingw32msvc/include/winsock2.h" 3 Look like a bug in header in case of mingw. Roumen |
From: Keith M. <kei...@us...> - 2008-02-03 16:03:54
|
On Sunday 03 February 2008 13:08, NightStrike wrote: > On 2/3/08, Tor Lillqvist <tm...@ik...> wrote: > > Is this how you approach programming in general? Just randomly try > > things without looking at recommended practice or code samples. I > > very > > Yet another reason why of all the mailing lists I'm on, this one is > the absolute worst...... Well, no one is forcing you to be here; if you don't like what you see, you may just quietly go away, but please, let's not have any flame wars on the list. In fact, Tor did raise a perfectly valid point; (thanks Tor for the pertinent reminder). It is common on MSDN, to see documentation for API functions, which says `defined in foo.h; include windows.h'. The implication of this is that foo.h is present in the headers directory, but you are not expected to include it directly in your own code; you are to include windows.h, which will take care of including foo.h for you. Your test for which headers have an inherent dependency on windows.h *is* naive, for it doesn't recognise this scenario. I am not saying that your patch should be rejected out of hand, but it will require careful review. If you have added `#include <windows.h>' to files which are themselves intended to be included as a consequence of including windows.h, then you have erroneously introduced circular references. You may not notice the error, because you are protected by guard logic, designed to prevent multiple inclusion of the headers in question, but it is nevertheless an error, which should be avoided. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2008-01-30 12:19:40
|
Quoting Dave Korn <dav...@ar...>: > On 30 January 2008 08:49, Vincent Torri wrote: > >> On Tue, 29 Jan 2008, NightStrike wrote: >> >>> Is it required that every program #include <windows.h> before using >>> most of the mingw headers? >> >> Not always. See msdn. For example, when using sockets, you lay just need >> winsock2.h >> > > Well, that's because winsock2.h #includes windows.h anyway, pretty much > first thing it does. > So for completeness the MinGW rule is "You must #include <windows.h> before any other header." If you decide to follow other rules then look elsewhere for help. Earnie |
From: Keith M. <kei...@us...> - 2008-02-02 15:30:46
|
On Wednesday 30 January 2008 12:19, Earnie Boyd wrote: > Quoting Dave Korn <dav...@ar...>: > > On 30 January 2008 08:49, Vincent Torri wrote: > >> On Tue, 29 Jan 2008, NightStrike wrote: > >>> Is it required that every program #include <windows.h> before > >>> using most of the mingw headers? > >> > >> Not always. See msdn. For example, when using sockets, you lay > >> just need winsock2.h > > > > Well, that's because winsock2.h #includes windows.h anyway, pretty > > much first thing it does. > > So for completeness the MinGW rule is "You must #include <windows.h> > before any other header." If you decide to follow other rules then > look elsewhere for help. When I first read this, I thought `that's a rather draconian rule'; indeed, in my own code, it would be honoured more in the breach, than in the observance thereof. However, since my code falls mostly into this category:-- On Wednesday 30 January 2008 09:10, Tor Lillqvist wrote: > And of course, programs that use just standard C library functions > have no need at all to include <windows.h>. They just need <stdio.h>, > <stdlib.h>, etc, like on any C89 platform. ...it would seem that such a `rule' has no relevance whatsoever. On Wednesday 30 January 2008 12:30, Earnie Boyd wrote: > Oh, you make me need to change my rule. ;D Surely, the rule should be that any compilation unit, which refers to Microsnot specific functions, (e.g. those whose names are uglified by a leading underscore, or have mixed case names), should include precisely those headers which are documented, on MSDN, as being required. To prescribe any other usage seems unnecessary. Regards, Keith. |
From: Keith M. <kei...@us...> - 2008-02-02 16:48:04
|
On Saturday 02 February 2008 15:31, Keith Marshall wrote: > Surely, the rule should be that any compilation unit, which refers to > Microsnot specific functions, (e.g. those whose names are uglified by > a leading underscore, or have mixed case names), should include > precisely those headers which are documented, on MSDN, as being > required. =A0To prescribe any other usage seems unnecessary. And, of course, this may be extended to software development framework,=20 whether provided by Microsnot or any third party; for each function you=20 call, you should #include any headers which are stated to be required,=20 in the appropriate supporting documentation. Regards, Keith. |
From: Keith M. <kei...@us...> - 2008-02-02 16:55:50
|
On Saturday 02 February 2008 16:48, Keith Marshall wrote: > this may be extended to software development framework, s/software development framework/any &/ Regards, Keith. |
From: Greg C. <gch...@sb...> - 2008-02-02 17:15:34
|
On 2008-02-02 16:49Z, NightStrike wrote: > > [...] I tried individually > compiling every header in mingw with something like this in a script > where $file is each .h header: > > #include <$file> > int main() {return 0;} This tests for the desirable property Lakos calls 'closure'. I test it automatically before committing any header to my own repository. BTW, you can test it this simpler way: http://article.gmane.org/gmane.comp.gnu.mingw.user/20528 | g++ -xc++ -fsyntax-only eraseme.hpp without creating any dummy main module. > The number of errors drops considerably when I change it to: > > #include <windows.h> > #include <$file> > int main() {return 0;} > > > So basically, a number of mingw headers won't compile unless windows.h > is also included. If those headers require windows.h, I would think > that they should include it themselves. I agree. > I am assuming that I am misunderstanding something here that everyone > sees very clearly. Could you enlighten me? See the last paragraph of: http://article.gmane.org/gmane.comp.gnu.mingw.user/25389 I think it's an ancient msw pitfall that we needn't perpetuate, so I'd be happy if you want to fix it. |
From: Keith M. <kei...@us...> - 2008-02-02 17:54:57
|
On Saturday 02 February 2008 17:15, Greg Chicares wrote: > On 2008-02-02 16:49Z, NightStrike wrote: > > [...] I tried individually > > compiling every header in mingw with something like this in a > > script where $file is each .h header: > > > > #include <$file> > > int main() {return 0;} > > This tests for the desirable property Lakos calls 'closure'. > I test it automatically before committing any header to my > own repository. BTW, you can test it this simpler way: > http://article.gmane.org/gmane.comp.gnu.mingw.user/20528 > > | g++ -xc++ -fsyntax-only eraseme.hpp > > without creating any dummy main module. It's also a feature that is checked by autoconf's AC_CHECK_HEADER macro, (which does create, and subsequently deletes, a temporary source file). > > The number of errors drops considerably when I change it to: > > > > #include <windows.h> > > #include <$file> > > int main() {return 0;} > > > > > > So basically, a number of mingw headers won't compile unless > > windows.h is also included. If those headers require windows.h, I > > would think that they should include it themselves. > > I agree. So do I. However, do note that this scenario isn't exclusive to windows.h; some implementations of the standard C library provide headers with an internal dependency on, say, `sys/types.h', yet they don't automatically #include it; (the accompanying manpages would simply state the requirement to '#include <sys/types.h>' before the applicable dependent header). > > I am assuming that I am misunderstanding something here that > > everyone sees very clearly. Could you enlighten me? > > See the last paragraph of: > http://article.gmane.org/gmane.comp.gnu.mingw.user/25389 > I think it's an ancient msw pitfall that we needn't > perpetuate, so I'd be happy if you want to fix it. Of course, patches will be welcome. In the meantime, if you are looking for an autoconf strategy to check for header foo.h, which may depend on windows.h, you could use:-- AC_CHECK_HEADERS([windows.h]) AC_CHECK_HEADERS([foo.h],[],[], [#ifdef HAVE_WINDOWS_H #include <windows.h> #endif ]) Do note the use of AC_CHECK_HEADERS, rather than AC_CHECK_HEADER; this is simply for greater convenience in updating config.h -- see the autoconf documentation, for the explanation. Regards, Keith. |
From: NightStrike <nig...@gm...> - 2008-02-02 19:05:06
|
On 2/2/08, Greg Chicares <gch...@sb...> wrote: > I think it's an ancient msw pitfall that we needn't > perpetuate, so I'd be happy if you want to fix it. I would if you'd be so kind as to tell me where in cvs the headers are. I can't seem to find them. |
From: Greg C. <gch...@sb...> - 2008-02-02 19:23:19
|
On 2008-02-02 19:05Z, NightStrike wrote: > On 2/2/08, Greg Chicares <gch...@sb...> wrote: >> I think it's an ancient msw pitfall that we needn't >> perpetuate, so I'd be happy if you want to fix it. > > I would if you'd be so kind as to tell me where in cvs the headers > are. I can't seem to find them. I think you'd want the 'mingw-runtime' and 'w32api' links here: http://mingw.org/MinGWiki/index.php/official%20CVS |