I like to use #pragma directives for library linkage and warning suppression in VC++ 2010 instead of Visual Studio project settings. The reason is they are more visible, and that information is not lost if the Visual Studio .suo file is nuked or destroyed.
So in a line like:
#pragma warning( disable: 4018;4482;4996;4800)
That's supposed to disable the warnings I'm ignoring atm (note: please suppress warnings regarding the suppression of warnings being a bad practice), but they clearly won't take effect until they get encountered in the compilation process..
So what file should I put these warnings suppressors in? Which is the first file to be compiled?
I put it in the file with main() in it, but that didn't work (you still see the warnings unless you put it in Project settings)
stdafx.h
comes to mind, if you have to put it in a file. (Just make sure you include it.)
Otherwise, just put it in the C/C++ project settings (in "Advanced").
Related
I'm using Microsoft Visual Studio Professional 2017 to build a project that uses the Poco libraries.
Background:
Don't know if this is pertinent, but I'll just mention that I manually downloaded and built Poco (and all the other libs needed), and everything went fine for years. Now I switched to using Miniconda3 to manage my libraries, installing Poco via conda install -c conda-forge poco and changing the relevant include paths from
$(POCO_DIR)/Foundation/include
$(POCO_DIR)/Util/include
...
to just
$(CONDA_LIBS)/include
with the system variable $(CONDA_LIBS) = D:\CodeLibraries\conda_libs\Library. This CONDA_LIBS directory exists and contains an include/Poco/ subdirectory with all the Poco header files and subdirs.
Problem:
The project compiled fine. I got a linker error, and while digging into this I found some odd behavior of Visual Studio 2017:
When I'm moving the cursor to an #include directive using any Poco header file, e.g.
#include "Poco/DateTime.h"
I can usually type CTRL+SHIFT+G to open and jump to the file in question.
This doesn't work anymore, and I get a popup telling me
D:\CodeLibraries\conda_libs\Library\include\oco\atetime.h
Cannot open file.
Note the missing letters in \(P)oco\(D)atetime.h. Note, also, that a file is found, but cannot be opened.
When I try this with a header file in a subdirectory like
#include "Poco/JSON/Parser.h"
I get the message
D:\CodeLibraries\conda_libs\Library\include\oco\son\rser.h
Cannot open file.
Note the missing letters "P", "J", and "Pa"(?!) in (P)oco\(J)SON\(Pa)rser.h.
Additional information:
The same error pops up when I drag-and-drop a Poco header file from the Windows Explorer into Visual Studio (!)
I can open these files from the Open File dialog (CTRL+O)
I can still use the CTRL+SHIFT+G shortcut to open my own header files in my project, and to open other library header files like gdal.h or boost headers
if I #include "oco/ateTime.h" (note the missing letters) and attempt to open it via CTRL+SHIFT+G I get the expected message "File 'oco/ateTime.h' not found in current source file's directory or in build system paths", with the paths listed below including D:\CodeLibraries\conda_libs\Library/include.
Question:
Any idea why both the CTRL+SHIFT+G shortcut and the drag-and-drop operation fail for Poco header files?
EDIT:
Please note:
I'm not asking about generic "File not found" errors: I can usually handle my include and lib paths quite well, thank you
slashes and backslashes can be used pretty much interchangedly in Visual Studio for the last couple of years at least
"Cannot open File" error could be due to a misconfiguration in your project include and source paths or due to a third-party extension or maybe even due to a corrupt/buggy IDE, but it has nothing to do with linker errors as you have also mentioned. You have also confirmed that the files are getting compiled, so this is surely some issue with the IDE's built-in code navigator or an extension.
With respect to linker errors, the project Configurations, lib target, library & header file versions you are referring to should match while linking against third-party libraries.
These are some general checklists for linking third-party libraries:
Runtime library: MT, MTd, MD, MDd, etc
Character set: Unicode or Multibyte
Target compiler
Target Machine
Subsystem
Whether the third-party library being used has additional dependencies, and you are properly linking the exact version of them.
These are checklists specific to POCO:
POCO version you are referring to in header files vs linker path
configurations.
OpenSSL version you are linking your project against, if you are
using SSL, Crypto and NET modules of POCO.
The same setup on my machine (but with VisualStudio 2019 configured for VisualStudio 2017 target) works just fine.
Odd.
When I returned to the office today, I wanted to look into this again to see if I could find out more about IntelliSense not finding POCO headers and about the odd dropping-characters thing in the error message, but it works now:
yes, I can once more jump to a POCO header file by moving my cursor to the #include line and hitting CTRL+SHIFT+G.
No idea if it was restarting VS that fixed this, or fixing the linker error -- which was trivial, BTW, and I might even have done at the side that while writing this question. Unfortunately I either didn't recheck for broken IntelliSense behaviour after the linker fix, or didn't bother recording that IntelliSense still was broken afterwards.
So: no real closure, I'm afraid.
EDIT: Ramesh Kambadaasan's answer suggests that a workaround might be to delete the IntelliSense DB file(s) and to restart VS to force a project re-parse. I'll try that next time.
In Windows you should use "\" as a directory seperator, not "/".
My guess is that VS replaces your "/" with "\", then the first letter of every word is an unescaped character.
Try to replace your "/" with "\\".
I can't seem to be able to suppress warnings in my solution in Visual Studio 2017 by going into Project Settings > Build > Suppress warnings:
Even when I clean - build, rebuild, etc... the solution, Visual Studio keeps bringing up these warnings for me.
I brought this up with a visualstudio.com report yesterday and it's "triaged" at the moment. Is there an alternative way to suppress warnings in the solution, without marking every single reference?
Version: 15.6.2
Update:
This is wierd.
Visual Studio 2017 uses a semicolon by default, but comma worked.
The way I do it solution-wide is to create a specific suppression file, for instance GlobalSuppressionsForTestProjects.cs, in a convenient solution-level location.
Then for each project of the solution where I want the suppression definitions applied, I add a link to the suppression file:
right-click on project -> Add -> Existing Item
in selection dialog, navigate to the suppression file
click on Add as Link
I learned this trick from this post where the same way was applied for AssemblyInfo.cs files.
I usually use pragma directives:
#pragma warning disable 1591
// whatever member is lacking xml comments, or even the whole file
#pragma warning restore 1591
Verbatim from the link above:
disable: Do not issue the specified warning message(s).
If you really want to disable warnings solution-wide, there's no way to do it.
All compilation options are specified on the project level. MSBuild exists below the level of solutions.
But it can be done project-wise, just like you were doing above; the only thing I would change is separating those codes using a comma and not a semicolon like in your picture (and without a comma in the end), e.g.:
1591,1701,1702,1705
That's because compiler options use a comma.
You may just need to restart Visual Studio. This worked for me, and FYI we do not need to include the CS part of the error in your textbox (it would still work as written though, but you only need the number for this.) You have certainly restarted VS in the years since first asking the question, but for anyone having this problem today, I hope this helps.
I had the same issue with the same warning (CS1591). So for "Suppress warnings" in the properties to actually work (rather than the #pragma solution which is a legitimate work-around but might be unnecessary keyboard time after a restart) you might just need to restart Visual Studio.
I am getting a strange Intellisense error in VS 2010. I searched the Internet with no luck. It seem that no one else got this error before.
IntelliSense: PCH warning: header stop needs to be at global scope.
An intellisense PCH file was not generated.
Following this many other errors as it stops indexing. This happens to the recent files that I have added. I have many files in my project (278) and this happens to the most recent 5-6 of them. May be I did something it doesn't like or may be there is a limitation.
Since I couldn't found this error even in the documentation, I would like to learn the reason as well as a possible solution. Note that, I have tried to delete ipch folder and sdf file to get them generated a new. The error is given to the last line of a file. My code heavily uses templates.
EDIT:
I noticed my ipch folder is mostly empty. This probably means that entire precompiled header generation fails, rather for those files. Still, intellisense partially works, but not for those files.
This error is generated when you forget a ";" after a class declaration, for example:
#ifndef _MYCLASS_H
class MyClass {
...
public:
...
}
#endif <--- VS2010 report here the error PCH: warning...
If you put a ";" after the closing "}" the error go away. I'm not saying this is the only cause, I'm just saying that I found that error with the missing ";" in the mentioned place.
PCH stand for "pre-compiled header" - you'll need to make sure you have these configured correctly.
The error message seems to be saying that the header configured as the 'stop' for precompiled headers is being included in a nested fashion (ie., some other header is including it). By default, a solution will use stdafx.h as the 'stop' header and the idiom is that stdafx.h will be the first header included in any .cpp or .c file. Don't include stdafx.h in any other header.
The best information about how Intellisense works and how to troubleshoot it come from the Visual C++ Team Blog.
A few articles that might be helpful:
Troubleshooting Tips for IntelliSense Slowness
Precompiled Header Files in Visual Studio 2010
IntelliSense History, Part 1
IntelliSense, Part 2 (The Future)
My initial feeling is that it could be a file encoding problem, but anyway here's how I would approach figuring it out...
Create a brand new solution, does the intellisense work? If not then a VS reinstall might be in order.
If intellisense works in a different solution then there are 2 possibilities: something in your solution is screwy, or something in your folder hierarchy is screwy (permissions maybe?)
I'd delete the entire solution folder and get the latest from source control.
If it still occurs after that and you really want to find the cause, then you could remove a load of files from the project, see if the intellisense now works, remove some more... until a) you run out of files or b) you find the file that causes the error.
If a) then make a brand new solution and add your files and projects to it. If that works then compare your new solution/project files with the old ones to see what's different.
If b) then add the files back in and start pruning until you find the offending line.
I use an Oracle precompiler for embedded SQL. I'm moving some code from VC++ 6.0 to VStudio 2010.
I place database calls in a single source code module named "dbcalls.pc" - that gets passed to the precompiler which produces "dbcalls.cpp" which then gets passed on to the compiler and linker like all other .cpp files.
Under VC6 I do a compile on my custom build .pc file manually - ie; rt click the dbcalls.pc file and choose compile. Then due to a bug in the specific version of the Oracle precompiler I use I have to open the .cpp and insert #include "stdafx.h" at the top of the .cpp produced by by the precompiler - I have a macro that does this. Then I can perform a build on the entire project and the VC6 IDE will NOT attempt to re-run the custom build.
In VStudio 2010, I have replicated this with one important exception/problem - if I configure the dbcalls.pc file to be excluded from the build under properties (where it is specified as being of type custom build) then I am unable to rt click the file and choose compile.
If I set the property to be included in the build I can rt click and manually build the .pc into the .cpp but then after I alter the .cpp when I run a build for the project it reruns the custom build and removes my changes. I'm forced to go back and forth with the properties dialog and change the "exclude from build" setting. This is a royal PITA that does not happen in VC6.
Can anyone suggest workaround? Obviously if the precompiler did not have this bug then all would be good but moving to another version of the pc is not currently in the cards.
thoughts?
OK - I'm not sure why - perhaps I swung the chicken over my head just the right amount of times.. - but it's working correctly now.
I resolved another issue I had with macro arguments to the precompiler in the custom build dialog and once I did that it started doing the conditional build correctly (or at least as I expected it to work).
Shrugged my shoulders a few times and said "case closed".
I'm using a library from CGAL which during the linking stage of my code compilation produces a lot of linking warnings of this form:
warning LNK4099: PDB 'vc80.pdb' was not found with 'gmp-vc80-mt-sgd.lib' or at 'vc80.pdb'; linking object as if no debug info
How do I turn off this specific linker warning under Visual C++/Studio 2008?
Note that I do not have any control on the external (CGAL) library which I am using. I cannot/donot want to get into recompiling the external library. Hence, the need to fix the messages at my end.
Add the following as a additional linker option:
/ignore:4099
This is in Properties->Linker->Command Line
Update 2018-10-16
Reportedly, as of VS 2013, this warning can be disabled. See the comment by #Mark Ransom.
Original Answer
You can't disable that specific warning.
According to Geoff Chappell the 4099 warning is treated as though it's too important to ignore, even by using in conjunction with /wx (which would treat warnings as errors and ignore the specified warning in other situations)
Here is the relevant text from the link:
Not Quite Unignorable Warnings
For some warning numbers, specification in a /ignore option is
accepted but not necessarily acted upon. Should the warning occur
while the /wx option is not active, then the warning message is still
displayed, but if the /wx option is active, then the warning is
ignored. It is as if the warning is thought important enough to
override an attempt at ignoring it, but not if the user has put too
high a price on unignored warnings.
The following warning numbers are affected:
4200, 4203, 4204, 4205, 4206, 4207, 4208, 4209, 4219, 4231 and 4237
(For the record and before the thread disappears on the msdn forums)
You can't disable the warning (at least under VS2010) because it is on the list of the warnings that can't be disabled (so /wd4099 will not work), but what you can do instead is patch link.exe (usually C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\link.exe) to remove it from said list . Sounds like a jackhammer, i know. It works though.
For instance, if you want to remove the warning for 4099, open link.exe with an hex editor, goto line 15A0 which reads 03 10 (little endian for 4099) and replace it with FF 00 (which does not exist.)
For the benefit of others, I though I'd include what I did.
Since you cannot get Visual Studio (2010 in my case) to ignore the LNK4204 warnings, my approach was to give it what it wanted: the pdb files. As I was using open source libraries in my case, I have the code building the pdb files already.
BUT, the default is to name all of the PDF files the same thing: vc100.pdb in my case.
As you need a .pdb for each and every .lib, this creates a problem, especially if you are using something like ImageMagik, which creates about 20 static .lib files. You cannot have 20 lib files in one directory (which your application's linker references to link in the libraries from) and have all the 20 .pdb files called the same thing.
My solution was to go and rebuild my static library files, and configure VS2010 to name the .pdb file with respect to the PROJECT. This way, each .lib gets a similarly named .pdb, and you can put all of the LIBs and PDBs in one directory for your project to use.
So for the "Debug" configuraton, I edited:
Properties->Configuration Properties -> C/C++ -> Output Files -> Program Database File Name from
$(IntDir)vc$(PlatformToolsetVersion).pdb
to be the following value:
$(OutDir)vc$(PlatformToolsetVersion)D$(ProjectName).pdb
Now rather than somewhere in the intermediate directory, the .pdb files are written to the output directory, where the .lib files are also being written, AND most importantly, they are named with a suffix of D+project name. This means each library project produduces a project .lib and a project specific .pdb.
I'm now able to copy all of my release .lib files, my debug .lib files and the debug .pdb files into one place on my development system, and the project that uses that 3rd party library in debug mode, has the pdb files it needs in debug mode.
I suspect /ignore is a VC6 link.exe option.
for VS2005 and VS2008's linker there's no documented /ignore option available, but the linker looks just ignore the "/ignore:XXX" option, no error and no effect.
The PDB file is typically used to store debug information. This warning is caused probably because the file vc80.pdb is not found when linking the target object file. Read the MSDN entry on LNK4099 here.
Alternatively, you can turn off debug information generation from the Project Properties > Linker > Debugging > Generate Debug Info field.
EDIT: don't use vc80 / Visual Studio 2005, but Visual Studio 2008 / vc90 versions of the CGAL library (maybe from here).
Linker Tools Warning LNK4099:
You could also compile with /Z7, so
the pdb doesn't need to be used, or
remove the /DEBUG linker option if you
do not have .pdb files for the objects
you are linking.
You cannot disable linker warning 4099, as said #John Weldon.
You should rebuild library with some project configuration changes. You have several options:
Save PDB file with debug information is same folder where you save .lib file. Set value "$(OutDir)$(TargetName).pdb" to Properties->C/C++->Output Files-Program Database File Name
Save debug information in .lib file. Set value "C7 compatible (/Z7)" to Properties->C/C++->General->Debug Information Format
Disable generation debug information for this library. Remove value from Properties->C/C++->General->Debug Information Format
In case anyone is looking to add the /ignore to a property sheet rather than modify many projects individually, you can add it as follows:
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<Link>
<AdditionalOptions>/ignore:4099 %(AdditionalOptions)</AdditionalOptions>
</Link>