I just turned on all warnings (/Wall) and treat all warnings as errors (/WX). I suddenly went from 0 warnings to 1329 error-warnings.
The thing is, 99% of those warnings are not in files I've written. Part of them are in the standard library, while others are in libraries I'm using with my project.
How do I tell Visual Studio to perform this kinds of checks only for files that I've written (which are a part of the project directly) while ignoring everything else?
Note that all my own source files will be within a single folder, as will any library includes (but not the same as my source files).
EDIT:
I've realized I can wrap all includes I don't want checked between two pragmas, for example:
#pragma warning(push, 0) // Ignore warnings in non-project files.
#include "volk.h"
#include "glfw3.h"
#include <assert.h>
#include <cstdio>
#include <stdexcept>
#include <vector>
#pragma warning(pop);
However, in this case, I have several warnings present in file xmemory which are still being reported. They appear in function _Adjust_manually_vector_aligned, but I don't know where to go from here.
Note that this warning appears even if I wrap my whole (and only) file in the pragmas above.
While wrapping includes in #pragma warning(push, 0) and #pragma warning(pop); will work for flags W0 to W4, Wall seems to contain warnings that are not affected by the pragmas above. It is by design:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/891a02d2-d0cf-495a-bcea-41001cf599de/pragma-warningpush-0-cant-disable-wall-warning-on-visual-studio-2017?forum=vcgeneral
Related
The cppreference.com and the cplusplus.com say that it's defined in <utility>. But my IDE sends me to "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\type_traits".
Cant't understand why.
The standard only specifies that #include <utility> gives you access to std::move. It does not require that definition to physically be present in that header file. The standard library is free to be organized internally as implementers see fit. For example, <utility> could consist of only #include <utility_internal> (which then contains the actual library implementation) - nothing in the standard forbids this.
In Microsoft's implementation of the standard library, <utility> has an #include <type_traits>. Thus, if you do #include <utility>, you will get std::move. That's all you should have to care about.
According to AutoIt's online reference:
It is quite common to have the same "#include " line in several of the files included included in a script. If the same file were to be included several times, it is quite likely that this would generate a "Duplicate function" or "Cannot redeclare a Const" error. So when writing a script intended for use as an include file, add #include-once to prevent that file from being included more than once. Note that the #include-once line must be placed at the top of the script and before any other #include lines.
It is not recommended to add a #include-once line to scripts which are not intended to be used as include files within other scripts.
So #include-once should not be used in scripts that are not intended to be included in other scripts. Why?
If the benefit of using #include-once is to prevent errors triggered by duplicate #include, then what is the benefit(s) of using #include over #include-once?
"… what is the benefit(s) of using #include over #include-once?"
None; they serve different purposes.
#include <filename.au3> includes filename.au3. #include-once (no parameters) prevents a file containing that directive from being included more than once.
If two different include files contain #include <FileConstants.au3> and FileConstants.au3 contains #include-once, then FileConstants.au3 does not get added again on inclusion of the second file (preventing constant- and function re-declaration errors). Usually every to be separately included file starts with #include-once.
"So #include-once should not be used in scripts that are not intended to be included in other scripts. Why?"
It serves no purpose. Effects (if any) classify as undocumented behavior (unintended by developers and subject to unannounced changes).
"When should #include be used over #include-once?"
You could use #include to execute code from another file at a certain (or multiple) other location(s) from within a file.
I found the explanation defining WIN32_LEAN_AND_MEAN "reduces the size of the Win32 header files by excluding some of the less frequently used APIs". Somewhere else I read that it speeds up the build process.
So what does WIN32_LEAN_AND_MEAN exclude exactly? Should I care about this pre-processor directive? Does it speed up the build process?
I've also seen a pre-processor directive in projects named something along the lines of extra lean. Is this another esoteric pre-processor incantation I should know about?
According the to Windows Dev Center WIN32_LEAN_AND_MEAN excludes APIs such as Cryptography, DDE, RPC, Shell, and Windows Sockets.
Directly from the Windows.h header file:
#ifndef WIN32_LEAN_AND_MEAN
#include <cderr.h>
#include <dde.h>
#include <ddeml.h>
#include <dlgs.h>
#ifndef _MAC
#include <lzexpand.h>
#include <mmsystem.h>
#include <nb30.h>
#include <rpc.h>
#endif
#include <shellapi.h>
#ifndef _MAC
#include <winperf.h>
#include <winsock.h>
#endif
#ifndef NOCRYPT
#include <wincrypt.h>
#include <winefs.h>
#include <winscard.h>
#endif
#ifndef NOGDI
#ifndef _MAC
#include <winspool.h>
#ifdef INC_OLE1
#include <ole.h>
#else
#include <ole2.h>
#endif /* !INC_OLE1 */
#endif /* !MAC */
#include <commdlg.h>
#endif /* !NOGDI */
#endif /* WIN32_LEAN_AND_MEAN */
If you want to know what each of the headers actually do, typing the header names into the search in the MSDN library will usually produce a list of the functions in that header file.
Also, from Microsoft's support page:
To speed the build process, Visual C++ and the Windows Headers provide
the following new defines:
VC_EXTRALEAN
WIN32_LEAN_AND_MEAN
You can use them to reduce the size of the Win32 header files.
Finally, if you choose to use either of these preprocessor defines, and something you need is missing, you can just include that specific header file yourself. Typing the name of the function you're after into MSDN will usually produce an entry which will tell you which header to include if you want to use it, at the bottom of the page.
Complementing the above answers and also "Parroting" from the Windows Dev Center documentation,
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 ..
Here's a good answer on the motivation for it from Raymond Chen's blog:
https://devblogs.microsoft.com/oldnewthing/20091130-00/?p=15863
...defining WIN32_LEAN_AND_MEAN brought you back to the 16-bit Windows philosophy of a minimal set of header files for writing a bare-bones Windows program. This appeased the programmers who liked to micro-manage their header files, and it was a big help because, at the time the symbol was introduced, precompiled header files were not in common use. As I recall, on a 50MHz 80486 with 8MB of memory, switching to WIN32_LEAN_AND_MEAN shaved three seconds off the compile time of each C file. When your project consists of 20 C files, that’s a whole minute saved right there.
Is there a gcc macro that allows me to identify whether something is being compiled in 64bit mode?
Duplicate Question:
Is there a GCC preprocessor directive to check if the code is being compiled on a 64 bit machine?
__LP64__
Seems to be what you want.
And you could also, at least on Linux,
#include <features.h>
#include <endian.h> // perhaps you skip that
#include <limits.h>
#include <stdint.h>
Then <bits/workdsize.h> gets included and gives you __WORDSIZE (either 64 or 32)
But why do you ask and why using the standard types provided by <stdint.h> is not enough for you?
template <class T>
struct scalar_log_minimum {
public:
typedef T value_type;
typedef T result_type;
static
result_type initial_value(){
return std::log(std::numeric_limits<result_type>::max());
}
static
void update(result_type& t, const value_type& x){
if ( (x>0) && (std::log(x)<t) ) t = std::log(x);
}
};
i got the following error while trying to compile the above:
functional_ext.hpp:55:59: macro "max" requires 2 arguments, but only 1 given
max is not a macro, right? Then what is this error? BTW, I am using visual studio 2005
Also what is 55:59 --- 55 is the line number 59?
I find the many #defines that you encounter once you included windows.h very disturbing (not only max and min, but I also had problems with other generic words like Rectangle if I'm not mistaken). Therefore, I have developed the habit to include windows.h only when absolutely necessary, and never in header files. This reduces the pain to a small number of C++ files that are platform-specific.
Unfortunately some boost libraries (I believe thread and asio) do include windows.h in their headers, and I still run into this kind of silly problems from time to time.
My solution for the remainder of the situations where this causes problems is to #undef the problematic symbols after the inclusion of the header files.
You're including a header file somewhere that #defines max as a macro. The best solution would be to figure out where it's being defined, and inhibit it from being defined if possible. Alternatively, you could just #undef it:
#include <evil_header_which_defines_max.h>
#undef max
As others have noted, including windows.h is probably your problem. Microsoft provides a means to "turn off" parts of windows.h with preprocessor symbols. You can define these symbols as part of your build or directly in code.
Using preprocessor symbols to conditionally skip sections of windows.h may or may not be considered elegant but in the general case it is an easier, more general and more scalable solution than #undef.
Here's how to skip defining min or max as macros:
#define NOMINMAX
#include <windows.h>
Note that many include files will, at some point, include windows.h. In such cases setting up your defines at a more global level may be more convenient.
If you search through windows.h, you can find a bunch of other preprocessor symbols (e.g., NOOPENFILE, NOKANJI, NOKERNEL and many others) that can often be useful.
It's a macro called max that gets into the way as Adam explained. Another solution (more a "hotfix") may be to put parentheses around the function, to prevent it from being seen as a macro invocation:
return std::log((std::numeric_limits<result_type>::max)());