I have the latest build of VS 2019 on Windows 10. I am writing two DLLs in standard C++ (not .Net).
DLL #1 calls a function in DLL #2. I included the .lib file of DLL #2 in DLL #1.
The code compiles fine and the function call works perfectly at runtime. My issue is that green squiggles appear under the function name with the message: Function definition for 'RunJaguar' not found.
DWORD RunJaguar(EXTENSION_CONTROL_BLOCK* pECB);
My psychic powers suggest you should declare your DLL functions with "extern" to make Intellisense happy:
extern DWORD RunJaguar(EXTENSION_CONTROL_BLOCK* pECB);
Or more appropriately, use __declspec(dllimport) and __declspec(dllexport) for DLL exports and imports.
You could use warning pragma to avoid spurious Intellisense warning.
#pragma warning( push,n )//Specify the compilation warning level as Level n
//Your code
//...
#pragma warning( pop )//Restore the previous compilation warning level
Here is the level:
Warning
Level Meaning
-------- -------------------------------------------
0 Turns off emission of all warning messages.
1 Displays severe warning messages
2 Displays level 1 warnings plus certain, less-severe warnings, such
as warnings about hiding class members
3 Displays level 2 warnings plus certain, less-severe warnings, such
as warnings about expressions that always evaluate to true or false
4 (the default) Displays all level 3 warnings plus informational warnings
Related
I am using Visual Studio 2019 (updated to date, running on Windows) to rewrite old program code in cross-platform C++ language (Windows & Linux).
In the code, I am using the pre-compilation directives #if, #else, #endif to toggle platform-specific blocks of code.
Example:
76 #ifdef WINDOWS_OS
77 errno_t success = fopen_s(&arq, logConfigFileName.str().c_str(), "rt");
78 #else
79 arq = fopen(logConfigFileName.str().c_str(), "rt");
80 #endif
In the Visual Studio editor, everything looks correct (see screenshot).
Project selected: Windows, Debug, x86.
Lines 1 and 2 appear normally (active and without error indication) and lines 3 to 5 appear in gray indicating they are disabled, that is, it appears as it should be.
However, when compiling I get the error:
Error C4996 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
error on line 79, line that should be ignored by the compiler.
How can I fix this, so that my code can be compiled for both platforms without problems ?
You don't need to create / define macros to identify the OS.
Compiler do it already. See C++ compiling on Windows and Linux: ifdef switch for the list.
Problem solved.
The problem was in the definition of the WINDOWS_OS flag, I had defined it in the code with the #define WINDOWS_OS statement.
The IDE recognized the instruction, but the preprocessor didn't.
The solution was to include the WINDOWS_OS flag in the list of definitions in: Project Properties -> Settings Properties -> C++ > Preprocessor - Preprocessor Settings.
To me this does not make sense, my everyday IDE is Rad Studio and in it if you set a compiler directive in the code it is valid for everything.
Thank you all.
In Visual Studio, warning C4996 (using a deprecated function) is treated as an error, and code that uses deprecated functions doesn't compile at all.
There are various ways to disable C4996 entirely, either suppressing it for a single line, for a translation unit, or for an entire project. But what if I want it to still raise a warning, but allow compilation while not treating it as an error?
#include <iostream>
[[deprecated]]
void deprecated_function()
{
std::cout << "I function, but have been deprecated.\n";
}
int main() {
deprecated_function();
}
This doesn't compile at all.
#include <iostream>
[[deprecated]]
void deprecated_function()
{
std::cout << "I function, but have been deprecated.\n";
}
int main() {
#pragma warning(suppress: 4996)
deprecated_function();
}
This compiles, but doesn't issue a warning at all.
Is it possible to tell Visual Studio to emit a warning, but still allow compilation, for a deprecated function? I'm thinking of refactoring purposes, where I'd like to mark a function as deprecated, identify all the places it's used, but the code still compiles at each intermediate stage where some but not all uses of the deprecated function have been replaced.
I'm compiling using Visual Studio 2019 Community 16.8.4, warning level set to /W3, "Treat Warnings as Errors" set to "No". This particular warning seems to be treated as an error if it gets emitted at all.
Found a working solution. It turns out the relevant flag is actually "SDL checks", not "Treat Warnings as Errors". Flipping it from /sdl to /sdl- causes compilation to emit a warning while still compiling.
EDIT: If I want to keep all the SDL checks on except treating Warning C4996 as an error, I can use the flag /sdl in combination with the flag /w34996, which specifies that 4996 is treated as a level 3 warning instead of an error.
Deleting forward declared pointers leads to undefined behavior.
Examples:
https://gist.github.com/jatinganhotra/4144778
https://stackoverflow.com/a/14382111/399908
However, my Visual Studio (VS2012) compiler doesn't warn me about it.
Is this an unfixed VS2012 compiler bug?
Did I disable (or never enable) the corresponding warning?
Is this specific to some project setting?
Visual Leak Detector hinted me to the problem, but is there some method (pragma, code, macro, ...) to detect this at compile time?
The respective warning is C4150.
It should be active by default and it is categorized in warning level 2 (which should be active too, since default warning level is W3 afaik).
Note: Instead of lowering the warning level, try to pragma warnings in specific cases.
When using the std::map with types that use trivial, non-throwing, copy constructors, a compiler warning/error is thrown (warning level 4, release mode) for unreachable code in xtree. This is because the std::map has a try-catch in it that helps maintain the state of the tree in the case of an exception, but the compiler figures out that the catch statement will never be called if the stored elements don't throw. These warnings can be easily suppressed with the following lines at the top of the .cpp file:
#pragma warning(push)
#pragma warning(disable:4702)
#include <xtree>
#pragma warning(pop)
Is there a way to bypass this warning/error without changing the warning level, building in debug, suppressing the warning, or using a different type in the map? Is there plans to change this in the standard library?
Update:
Maybe it is compiler specific. I am using vc7.
The error is below:
c:\program files\microsoft visual studio .net 2003\vc7\include\xtree(1116) : error C2220: warning treated as error - no 'object' file generated
c:\program files\microsoft visual studio .net 2003\vc7\include\xtree(1116) : warning C4702: unreachable code
Apparently the xtree is used by the std::map.
Unfortunately it looks like xtree is part of the underlying implementation of map in VC7, and as such there isn't much that can be done to mitigate it. It looks like it's a bug in the standard library.
Is it a possibility to use a newer compiler? I'm fairly sure there are free downloads of more recent versions of the compiler you could use, and perhaps they've fixed this issue.
If that's not an option, probably the best solution is to wrap the include of map into your own private header, complete with a comment and the #pragma+include <xtree> lines you already discovered (in addition to an include of map. This way you hide the workaround from normal use.
I can inhibit many warnings in Visual Studio 2005 SP1 in the C/C++ Advanced property page, which causes the IDE to use the /wd switch on the command line which invokes the compiler. However, when I try to inhibit warning 4200 (nonstandard extension used : zero-sized array in struct/union), it still appears when I compile. (Of course it's justified; I'm just not in a position to fix the code, nor would it be worth bothering, because it's generated, and the warning is entirely benign under the circumstances.) Does anybody happen to know if this is a bug in the compiler? Or might there be something I can do about it?
To completely disable the warning in the file you can add the following to the top of the file
#pragma warning(disable:2400)
If you want some more flexibility other than a blanket disable for the file, the following page lists several other more fine grained options.
http://msdn.microsoft.com/en-us/library/2c8f766e(VS.80).aspx
It's unclear based on your information as to whether or not it's a bug in the compiler or a configuration issue. I would lean towards a configuration issue, specifically conflicting compiler options that is making it difficult to suppress the warning.
EDIT
OP mentioned they can't control the generated code so they can't directly include the pragma. If that's the case then try this trick. Say the file name is Generated.cpp. No longer include Generated.cpp as one of the files to compile. Instead create a new file called Example.cpp with the following contents
#pragma warning(disable:2400)
#include "Generated.cpp"
Now you'll get the text of Generated.cpp with the disabled warning by only compiling Example.cpp.
You mean like with pragma?
#pragma warning( disable : 2400 )