Why can't I include windows.h in afx(MFC) projects?
Typically, MFC application code includes afx.h or afxwin.h (the latter includes former). First two lines of windows.h are
#ifndef _WINDOWS_
#define _WINDOWS_
which means that _WINDOWS_ becomes defined if this header is included.
Afx.h includes afxver_.h and this header includes afxv_w32.h which contains following code:
#ifdef _WINDOWS_
#error WINDOWS.H already included. MFC apps must not #include <windows.h>
#endif
...
#include <windows.h>
So, if you include windows.h before MFC headers, you'll get this error generated in compile time and, as you can see, if you include afxwin.h you don't need to include windows.h yourself - it will already be included by afxv_w32.h.
Because in MFC you are not supposed to use it directly. AFAIR you should include afx.h instead, which in turn indirectly includes windows.h the proper way.
You can include windows.h; but you need to first include afx.h (or similar). If you got the error: "MFC apps must not #include <Windows.h>"; it is from including something like afx.h after including windows.h.
You might need to turn on 'show includes' if not sure how it got included.
Related
What's the current "best practice" regarding the inclusion of Qt header files when using a modern and recent C++ compiler (e.g. MSVC2015) with precompiled headers activated?
Example:
#include <QStringList>
#include <QTreeWidget>
#include <QListWidget>
vs.
#include <QtCore>
#include <QtGui>
What convention should I choose for a new project?
What are the benefits/drawbacks of either?
What is more common for new projects?
As far as I know, there is no specific limitation/recommendation/advantages/drawback with Qt includes and precompiled headers. When including third party header files (Qt or boost or whatever), the same rules apply.
In general (true for Qt includes, but also for any other third party includes, like STL for instance, and even when including your own code), you should make your includes minimal. The fewer files you include, the faster compilation will be. Including files you don't actually need will make compilation slower. Additionally, if such a header file you included but do not use, is edited/modified (which should not be the case for third parties header files, in general), any file including it will require to be recompiled, even if it does not really use the code included....
So the general rule is to only include files that you really need. So if your file only needs QStringList, prefer including <QtCore/QStringList> rather than <QtCore>.
If you are concerned about compilation time, also make sure you only include files from header files (.h) if necessary, if forward declaration can be used, use it and only include the necessary header file from your implementation (.cpp). This will drastically reduce compilation time of your project when a header file gets modified (read this).
Now, if your project has many files that includes some Qt files, you may use precompiled header to optimize compilation. Those files will then be compiled once and only once. However, as all your files will end up using the same precompiled header (itself including many many header files), you should only do this if:
The precompiled header files should mainly be third party header files, so that they are not meant to change. Because if on changes, then all your files will require to be recompiled...
The compiler must support precompiled header (else, compilation may work but may also end up being slower because every file will end up including all the precompiled header of the project...so probably more files than it actually needs).
I use next in all projects (for precompiled header):
#pragma once
#ifdef QT_CORE_LIB
# include <QtCore>
#endif
#ifdef QT_CONCURRENT_LIB
# include <QtConcurrent>
#endif
#ifdef QT_GUI_LIB
# include <QtGui>
#endif
#ifdef QT_WIDGETS_LIB
# include <QtWidgets>
#endif
#ifdef QT_MULTIMEDIA_LIB
# include <QtMultimedia>
#endif
#ifdef QT_NETWORK_LIB
# include <QtNetwork>
#endif
#ifdef QT_XML_LIB
# include <QtXml>
#endif
#ifdef QT_QML_LIB
# include <QtQml>
#endif
#ifdef QT_QUICK_LIB
# include <QtQuick>
#endif
#ifdef QT_SQL_LIB
# include <QtSql>
#endif
#ifdef QT_PRINTSUPPORT_LIB
# include <QtPrintSupport>
#endif
It will include necessary definitions only if you connect a module. Works well with msvs+qt addin or with cmake based projects (I use cotire).
Including less headers reduces compilation time, and only that, so if you do
#include <QtCore/QStringList>
compilation it's slightly faster than if you did
#include <QtCore>
If you are sure that you depend on everything in QtCore, include it, if not, include each header separately.
I am including a third party header and source file into my project.
At the top of the header there is this:
#if defined(WIN32) || defined(WIN16)
#ifndef MSDOS
#define MSDOS
#endif
#endif
#include <stdio.h>
#include <stdlib.h>
#ifndef MSDOS
#include <unistd.h>
#endif
#include "des.h"
The problem is that #if defined(WIN32) fails and the compilation fails when trying to #include unistd.h which I don't want to do.
I have third party project that works with this header file i.e. WIN32 is defined and it doesn't try to include In Visual Studio I did "Go To Definition" on "WIN32" and was taken to the following definition in WinDefs.h.
#define WIN32
I'm not sure this is where its getting WIN32 definition from, as the third party project does not appear to include "WinDefs.h".
So my problem is, how can I get WIN32 to be defined in my current new project?
Depends on your project setup. WIN32 is defined inside the windows header files, but you can pass it to the compiler as well ("-DWIN32" for gcc for example). Try it and see whether it compiles.
Visual Studio has the built-in define _WIN32. mingw-gcc has WIN32 and _WIN32 built-in so the project was likely tested using gcc. You might add
#if defined(_WIN32) && !defined(WIN32)
#define WIN32
#endif
or just add a -DWIN32 to the CFLAGS.
Check your includes. I am guessing that the third party header is included prior to the windows.h. So, in your main.cpp or equal it should be
#include <windows.h> // this will also include windefs.h
#include <thirdParty.h>
and not the other way around.
Hope that helps.
You can simply include the windows header files (windows.h) before including the third party header - as you already found out WIN32 is defined there but technicaly it could be defined anywhere (so if the third party project is not including the windows headers check if it's being defined in the compiler project settins directly).
BTW there is also a _WIN32 define that is set by the compiler, it's possibly a better idea to look for this define if checking if the code is being compiled under windows;
For those seeking answers to the
where is WIN32 defined
part of the questions, I've found it defined in:
minwindef.h
ole2.h
Note, I have no confidence that these are the only places it's defined. I expect there are probably other files where it's defined. Nevertheless, I thought this might help some people.
Some WIN32 defined in the compiler . Just like this，If you use the gcc for windows , WIN32 is defined . If you use the gcc for linux , WIN32 is not defined :)
So , the macros is a switch. You can define it to use somethine , and not define it to unuse something.
I'm deep in trouble with my project.
I have to link two radar with my program, but the first has its own library that uses winsock, while in the second I want to use winsock2.
How can i do that?
At the moment i get many redefinition errors from the includes within winsock.h and winsock2.h.
Take into account that the first radar library is already an DLL, i've got only a header and lib file (no source).
Thank you in advance for any answer.
You could possibly work around the compilation problem by structuring your code (and precompiled headers) so that no file includes both winsock.h and winsock2.h, this may mean either not using precompiled headers at all or using them in a more complex way than is normal in MFC projects...
You could wrap each DLL in a COM object and access them via COM from your main program. This has the advantage of completely separating the use of the two DLLs from your main compilation.
You could wrap each of the DLLs in a new DLL (one each) which provides an interface to your program that does not need the winsock headers in the interface headers.
Of course this may simply be an issue with your Windows.h include order, try putting this at the top of your precompiled header...
#ifndef _WINDOWS_
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#undef WIN32_LEAN_AND_MEAN
#endif
#include <winsock2.h>
To avoid conflicts with winsock2.h, I want to wrap my include of windows.h with WIN32_LEAN_AND_MEAN (I undef it after windows.h so as not to interfere with applications that include my headers). Doing this causes timeval to be undefined when winsock2.h isn't included. Including time.h doesn't define timeval either.
How can I get timeval defined (a) without having to include winsock2.h, (b) not requiring applications that include my headers to include winsock2.h before my headers, (c) allowing application to include winsock2.h if they need them, and (d) not having to define timeval myself, because it may already be defined by a header the parent application is including?
Remember that WIN32_LEAN_AND_MEAN is a compiler performance optimisation. Using it makes your apps compile somewhat faster at the expense of omitting some less-used parts of the Windows API.
You could use one of the more granular disables (NOIMM, etc), but these have even less impact on compile time than the LEAN_AND_MEAN one does.
Unless your project is very large and has long, onerous compile times I would simply stop using WIN32_LEAN_AND_MEAN.
Martyn
I don't define either of the LEAN_AND_MEANs, instead I explicitly do the following for each of the 'NOs' prior to including windows.h
// Exclude Input Method Manager (International stuff...one day)
#if !defined NOIMM
#define NOIME
#define NOIMM
#endif
// Exclude Metafile API
#if !defined NOMETAFILE
#define NOMETAFILE
#endif
This allows me to use the same StdAfx.h. With VS2010 I can include Winsock2 after windows.h without conflicts.
Stdafx is a little longer, but clearly documents what is included and excluded.
This is how I handle problems with winsock2.h (assuming Visual C++):
I configured the build system to always pass in /D_WINSOCKAPI_ to the compiler on the command line so that no winsock header files are ever implicitly included.
When I want to include winsock2.h, I do it via a proxy header file that does some preprocessor magic for me.
This is how my header file works:
#pragma push_macro("_WINSOCKAPI_")
#undef _WINSOCKAPI_
#include <winsock2.h>
#pragma pop_macro("_WINSOCKAPI_")
If you do this then you don't need to #define WIN32_LEAN_AND_MEAN and you can use winsock2.h only when needed.
I don't think what you want is possible. The timeval struct is defined in winsock.h and winsock2.h, thus you have to include one of those to get the definition. If you don't define WIN32_LEAN_AND_MEAN, windows.h will include winsock.h; this makes it impossible to include winsock2.h. If you define WIN32_LEAN_AND_MEAN, neither of the winsock header files are automatically included thus you don't get the definition for timeval. I think your best option is to require applications to include one of the winsock headers explicitly.
When I include winsock2.h, I get about 60 redefinition errors. I hunted around a bit a found some advice to include winsock2.h b4 including windows.h. I did that and that cleared up the errors. My problem and question concerns exactly how I should go about doing this. I did not explicitly include windows.h, it was done for me in stdafx.h or stdafx.cpp.
I added the include winsock2.h immediately b4 the include Windows.h in stdafx.h. Is this the right way to go about this or is there a better way?
Judging by a comment in program_name.rc I gather the windows.h include in stdafx.h may have been placed there as a result of some option or configuration parameter but I was unable to find this reference. Is there some way to specify what files are included in stdafx.h?
BTW, WIN32_LEAN_AND_MEAN was defined b4 calling windows.h in stdafx.h.
I am using Visual c++ 6.0 and 'Windows Server 2003 PSDK' The program is straight c++, no mfc, no net, just plain vanilla.
You can put pretty much whatever you want into stdafx.h. It's certainly fine to add your #include for winsock2.h before the windows.h. I'd move the WIN32_LEAN_AND_MEAN header so that it's defined before you include any other headers:
#define WIN32_LEAN_AND_MEAN
#include <winsock2.h>
#include <windows.h>
stdafx.h is a horrendous name for the precompiled header. I have no idea why Visual Studio still uses this for all the autogenerated projects. It gives the precompiled header an undeserved air of mystery. In my projects I usually set up the precompiled header to use 'precompiled.h' and 'precompiled.cpp'.
Noel Llopis has a great article on precompiled headers - 'The Care and Feeding of Precompiled Headers' if you want a bit more background info on what's going on here.
That should work okay. If you look in winsock2.h, you can see that it includes windows.h if it hasn't already been included.
You need to make sure that WinSock2.h is included BEFORE windows.h, make sure that wherever you're including WinSock2.h, it is included before stdafx.h and/or windows.h