16

I think it's universally accepted that #include <bits/stdc++.h> is bad practice, in part because it parses and includes every standard header, which is almost always unnecessary (it's also nonportable, but that's beyond my point). It's even worse when combined with using namespace std; because now you have a ton of common names in your namespace, like next.

Yet, it seems that #include <Windows.h> is mostly deemed to be OK (it's used by most Win32 programs I've seen), even though it conceptually does the same thing as a combination of #include <bits/stdc++.h> + using namespace std;.

According to Wikipedia:

windows.h is a Windows-specific header file for the C and C++ programming languages which contains declarations for all of the functions in the Windows API, all the common macros used by Windows programmers, and all the data types used by the various functions and subsystems. It defines a very large number of Windows specific functions that can be used in C.

Why is this the case? Is it not possible to include specific headers we use and not include <Windows.h>?

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
Aykhan Hagverdili
  • 28,141
  • 6
  • 41
  • 93
  • 1
    All the functions declarations in windows.h are declarations of dll functions. These dlls contains really lots of functions. You can exclude some of them from compilation. But including windows.h in precompiled headers should be ok. – armagedescu May 20 '20 at 19:28
  • 1
    It's OK because there's no reasonable alternative the majority of the time. – john May 20 '20 at 19:34
  • @john I am new to Windows programming. Why is including specific headers we need not a reasonable alternative? – Aykhan Hagverdili May 20 '20 at 19:35
  • 4
    The Microsoft documentation for its API says to include windows.h. While it also lists the specific header that contains the definition, I doubt that you could just include that one header. I would not be surprised if there is an order dependency on all those other windows headers (that you'd have to figure out on your own). – 1201ProgramAlarm May 20 '20 at 19:37
  • 1
    @Ayxan If you can find specific documented headers for what you need then fine. But for most Win32 API programming `#include ` is the only documented possibility. – john May 20 '20 at 19:37
  • really you almost always need include *windows.h*. think almost any another *h* file from windows sdk will not compile without include *windows.h* before it. many header files internal include *windows.h* too. possible you can define `WIN32_LEAN_AND_MEAN` before *windows.h* . and if you use precompiled headers this is not problem at all. – RbMm May 20 '20 at 20:10
  • it's base header file for WIndows API. if app's target is ONLY WIndows, you can't get away from that. If it is portable. I suggest create own header library that includes proper headers – Swift - Friday Pie May 20 '20 at 20:13

3 Answers3

20

Msdn documentation explicitly tells you (a) in which header file a function is declared and (b) which header file you are supposed to include.

Most functions tell you to include windows.h, for example SendMessage

Some function, that were added later or have very specific use cases, are only available through other header files, for example SetupDiEnumDeviceInfo.

So no, it is not bad practice to follow their advice. However, I strongly recommend disabling some parts of it before including via macro, e.g.

#define NOMINMAX
#include <Windows.h>

because otherwise you will get a min and a max macro that will interfere with std::min and std::max.

Timbo
  • 27,472
  • 11
  • 50
  • 75
  • The link you provided says it's `SendMssage` is in `winuser.h` – Aykhan Hagverdili May 20 '20 at 19:39
  • 6
    @Ayxan ... and literally the next two words are "(include Windows.h)". – Timbo May 20 '20 at 19:40
  • 2
    @Ayxan Basically the windows headers are a mess. And although it looks like you could include more specific headers for a particular task in practise it doesn't work out (at least not the last time I tried it, which was a while ago). – john May 20 '20 at 19:41
  • @Timbo I understood that part as "This header is included by Windows.h. You don't need to include it again if you've already included Windows.h". I am new to windows programming, not sure if that makes sense at all – Aykhan Hagverdili May 20 '20 at 19:42
  • @john your comment combined with [another comment](https://stackoverflow.com/questions/61921246/is-include-windows-h-bad-practice#comment109520446_61921246) seems to explain it for me. – Aykhan Hagverdili May 20 '20 at 19:44
  • If only C++ had namespaces, then we wouldn't need to use such strange macros. – Lundin Dec 16 '21 at 07:41
2

bits/stdc++.h is a compiler-specific header. If you compile your code with a different compiler it may or may not exist. It's not part of standard C++. It's a shortcut for access to the C++ standard library.

windows.h is an operating-system specific header. If you're compiling for Windows you need it, and every compiler that supports Windows will be okay with it. It doesn't necessarily come with the compiler; it comes with the Windows Software Development Kit. It provides access to the Windows API.

You might be able fine-tune your #include directives under Windows, but Windows is such a mess that unless you really want to spend time digging into it, you're better off just using windows.h.

Pete Becker
  • 74,985
  • 8
  • 76
  • 165
  • I understand your point. How come winapi is such a mess and no work seems to be done to either improve it or perhaps make a new C++ API? – Aykhan Hagverdili May 21 '20 at 13:56
  • 3
    @Ayxan -- because Microsoft. – Pete Becker May 21 '20 at 14:04
  • 4
    @ayx The Windows API is **huge** and literally several decades old. And it's used by hundreds of thousands of applications. I doubt that there's much you could conceivably change in the headers without breaking someone's build. It's easy to call it a mess. It's equally easy to ignore the significant investments made into cleaning it up. That effort goes by the name Windows Runtime. – IInspectable May 21 '20 at 23:21
  • @IInspectable interesting point. Do you mean Windows Runtime as in C++/WinRT is the new/clean WinAPI? – Aykhan Hagverdili May 22 '20 at 09:20
  • 2
    @ayx The Windows Runtime is independent of C++/WinRT. The latter projects the former and provides convenient access to the API for C++ developers. The Windows Runtime itself just offers a clean API surface, exposed in a language-agnostic way. It succeeds the Windows API as an interface to system services going forward. – IInspectable May 22 '20 at 10:08
1

There are various defines, in particular

#define WIN32_LEAN_AND_MEAN

which, if defined prior to the call to <windows.h>, will bypass some of the less-used windows headers.

CinCout
  • 9,486
  • 12
  • 49
  • 67
Tony Stark
  • 31
  • 2