3 ms·
When developing on Windows it pays significant dividends to manage your include files. There are a number of files provided as part of Visual Studio and/or the
by maximilianburke 15y ago
When developing on Windows it pays significant dividends to manage your include files. There are a number of files provided as part of Visual Studio and/or the Windows SDK that bring in a tremendous amount of large other files.
Unlike with Linux it's quite difficult to perform piecemeal inclusion of system header files because of the years of accumulated dependencies that exist. If you want to use the OS APIs for opening files, or creating/using critical sections, or managing pipes, you will either find yourself forward declaring everything under the moon or including Windows.h which alone, even with symbols like VC_EXTRALEAN and WIN32_LEAN_AND_MEAN, will noticeably impact your build time.
DirectX header files are similarly massive too. Even header files that seem relatively benign (the Dinkumware STL <iterator> file that MS uses, for example) end up bringing in a ton of code. Try this -- create a file that contains only:
#include <vector>
Preprocess it with GCC (g++ -E foo.cpp -o foo.i) and MSVC (cl -P foo.cpp) and compare the results -- the MSVC 2010 version is seven times the size of the GCC 4.6 (Ubuntu 11.10) version!
- ArbitraryLimits 15y agoI came here to say this. Anytime Unix people complain about slow builds "on Windows," 9 times out of 10 it's because they're ignoring precompiled headers. The other 1 time out of 10 it's because they're using configure scripts under cygwin and finding out how expenseive cygwin's implementation of fork() can be.