Compiling one of my projects that uses gRPC with the latest Visual Studio 2019 16.5 preview 2 compiler gives rise to this warning:
1>D:\...\grpcpp\impl\codegen\security\auth_context.h(38,19): warning C4996: 'std::iterator<std::input_iterator_tag,const grpc::AuthProperty,ptrdiff_t,const grpc::AuthProperty *,const grpc::AuthProperty &>': warning STL4015: The std::iterator class template (used as a base class to provide typedefs) is deprecated in C++17. (The <iterator> header is NOT deprecated.) The C++ Standard has never required user-defined iterators to derive from std::iterator. To fix this warning, stop deriving from std::iterator and start providing publicly accessible typedefs named iterator_category, value_type, difference_type, pointer, and reference. Note that value_type is required to be non-const, even for constant iterators. You can define _SILENCE_CXX17_ITERATOR_BASE_CLASS_DEPRECATION_WARNING or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning.
Before submitting a bug report, I thought I've check here if the gRPC developers are already aware of this?
gRPC is currently dependant on Absel that is reliant on C++11. You should avoid using two different C++ standards in your applications to avoid template incompatibilities. There is a longer discussion on Absel C++11 vs C++17 versions here: https://github.com/abseil/abseil-cpp/issues/259.
You can check out the Absel pages for more details at https://github.com/abseil/abseil-cpp.
The position that gRPC doesn't support C++17 is a little surprising. I might be missing it, but I don't see any mention on the main grpc page that anything beyond C++11 isn't supported. The only support matrix I was able to find was: https://grpc.io/docs/#official-support
In general both protobuf and gRPC usage will cause a slew of warnings in Visual Studio, unrelated to this error. For generated cc files, suppressing warnings 4267, 4996, and 4244 is helpful.
For this C++17 warning/error, since the issue is in a header, you'll hit the issue on your own, non-generated cpp files. You don't want to disable such warnings/errors on every file that uses the header, because then you'll mask your own issues. I currently work around by creating grpcpp.suppress_errors.h:
#pragma once
#pragma warning ( push )
#pragma warning( disable : 4996)
#include <grpcpp/grpcpp.h>
#pragma warning ( pop )
Then instead of including <grpcpp/grpcpp.h>, include grpcc.suppress_errors.h . It's a bit silly, but it will keep your own code clean from suppressions.
aggieNick02's answer didn't fix it for me. But I could could manage to suppress the errors in Visual Studio like so:
I added _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS; to the preprocessor definitions.
Not as optimal as aggieNick02's answer, but at least this kept me going.
I got grpc from vcpkg, if that info helps somebody:
1.37.0 3
dc35791a568aacf855355bcfcdff978ec22e69d3
2021-07-27
abseil (2021-03-24), c-ares (1.17.1), grpc (1.37.0), openssl (1.1.1k), protobuf (3.15.8), protobuf (3.15.8), re2 (2020-10-01), upb
(2020-12-19), zlib (1.2.11)
gRPC does not currently support C++17. We're currently using C++11. You should probably use whatever flags are necessary to have your compiler enforce C++11 semantics.
Related
I am trying to eliminate the warnings in my project so I can turn on the flag that treats warnings as errors. The project uses the boost library, specifically the Concept_check.hpp and cuthill_mckee_ordering.hpp files. The warnings 4510 and 4610 are shown in the concept_check.hpp file and I have tried to disable them using #pragma warning push and pop. The warnings are caused by the boost library trying to instantiate a class using the template found in concept_check.cpp when there is no constructor written for it.
My Question is this: Is there a more sure fire way that I can disable these warnings without modifying the boost code? I am using Visual studio 2010.
Perhaps you are looking in the wrong direction. As Alan Stokes pointed out, the warning is there for a reason. I have three hints that are perhaps not the answers you expect, but may bring an acceptable solution:
Instead of silencing the warning, just fix the error. I don't know your code, but there are other people that had a similar problem which was possible to fix by just declaring a variable.
Another question is: why do you want to turn all your warnings into errors? Is it really neccessary? I agree that normal code should always compile without warnings. But these warnings are not originating from your own code. Consider a static code-checker that warns you about issues where your compiler is blind about.
If you have to use -WX, move the offending code into a static object/library/module so you will be bothered about the warning only when you need to recompile this module. You could use specific compile options for this module, to get the warnings completely out of your way.
There is another possibility, but I'm not able to check whether it really works. According the Microsoft Documentation it is possible to set the warning level of specific warnings. (there are similar options for GCC). First, switch all warnings to error:
/WX
Then, set the warning level of the two offending warnings to zero:
/W04510 /W04610
A complete commandline would look like this:
cl source.cpp /WX /W04510 /W04610
The best solution would be to combine this with hint 3 above. This way, the specific compiler options are only used for the files that cause the warnings.
Maybe these solutions work.
You can disable specific warning from a .h file (#pragma warning( disable: ... ).
Currently i have a problem with the deprecated messages flooding my output and i want to stop it without disabling all deprecated messages. It is warning me about auto_ptr (which i don't even use in my own code). Even if it can't be done with a compiler flag, the std library looks like it could disable it, though i couldn't find out how:
#if _GLIBCXX_USE_DEPRECATED
template<typename> class auto_ptr;
#endif
You probably selected the -std=c++11 or -std=c++0x language dialect, or it's your GCC versions default setting.
std::auto_ptr is marked as deprecated with the current standard, in favor of the c++11 smart pointers from the dynamic memory management library.
" (which i don't even use in my own code)."
Are you sure that you don't even include any 3rd party (non standard) stuff, that might make use of std::auto_ptr<>?
"the std library looks like it could disable it, though i couldn't find out how"
Just make sure that this flag (_GLIBCXX_USE_DEPRECATED) is undefined, when compiling your code:
$ g++ -U_GLIBCXX_USE_DEPRECATED ...
How to scanf int8_t and other types without this error. I used "cinttypes" to get constants of patterns but that didn't help.
#include <cstdio>
#include <cstdint>
#include <cinttypes>
int main()
{
int8_t var;
scanf("%" SCNi8, &var);
printf("%" PRIi8 "\n", var);
return 0;
}
P.S. This error occures only in Debug, when building in Release it's OK.
P.P.S. Output is:
1>------ Build started: Project: SCANF_PROBLEM, Configuration: Debug Win32 ------
1> SCANF_PROBLEM.cpp
1>d:\study\scanf_problem\scanf_problem\scanf_problem.cpp(11): warning C4996: 'scanf': This function or variable may be unsafe. Consider using scanf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1> d:\visual studio\vc\include\stdio.h(283) : see declaration of 'scanf'
1> SCANF_PROBLEM.vcxproj -> D:\Study\SCANF_PROBLEM\Debug\SCANF_PROBLEM.exe
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
Even in C99, those extended integer types aren't required to exist, unless the documentation says they exist, more on that later... Even if those extended integer types do exist they're not required to have scanf format specifiers. See n1256 section 7.8.1p6 for this quote:
For each type that the implementation provides in <stdint.h>, the corresponding
fprintf macros shall be defined and the corresponding fscanf macros shall be
defined unless the implementation does not have a suitable fscanf length modifier for
the type.
As for C++, well... C++11 delegates that <cstdint> shall essentially be a wrapper for C99s <stdint.h>, and the functions it refers to be wrappers for the C99 equivalents.
Here's the kicker: Microsoft has never cared all that much about C99, to the extent that they're willing to document "N/A" for extended integer support, for example.
Make sure your compiler is configured to compile as C99 or later, or C++11 or later, and link to a C99-or-later-compliant standard library. SCNi8 may exist in the headers, but if scanf doesn't support it (which it won't, prior to C99/C++11 compliance) then you won't have any luck with it... and of course, make sure your standard library documents support for the implementation-defined features you intend to use.
Protip: If your filename ends in .c, Microsoft Visual Studio will attempt to compile your code as C89. That's probably not going to be helpful. MSVC++'s C99-compliance in terms of the standard library isn't too great even when you tell it to compile as C++11. You should probably learn how to determine which compiler/library versions you're using... while you're learning how to compile using the command line.
Protip #2: You can use LLVM/Clang in Visual Studio. Make sure you link to a C99-compliant standard library (e.g. not Microsoft).
Protip #3: You might want to change SCNi8 for PRIi8 when using printf...
Protip #4: See footnote 191 for this quote:
C++ implementations should define these macros only when __STDC_FORMAT_MACROS is defined
before <inttypes.h> is included.
You have run into a bug of Microsoft's C/C++ runtime library, cf. http://mfctips.com/tag/format/ or https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63417 (which reports this bug for gcc under mingw, which links against the Microsft libs).
"%hhd" just doesn't work; you must program around it (which isn't too hard, but sad).
I am not aware of a bug report to MS (i.e., I did not see anything when I tried to google it).
I am porting a project from Windows to Linux/Ubuntu, which involves using open software called "PST SDK"
(http://pstsdk.codeplex.com) written in c++. This has not been updated since 2010 but it works fine in
Windows and supposedly works/did work in Linux. I set up a demo program with nothing more than including
the header files (the library is all headers, nothing to link). I had a lot of errors but got them
fixed by using g++ instead of gcc, and fiddling with the location of the library files and required
boost files.
However once I tried making some calls, I ran into problems. I got a few things working, but the
following code:
std::vector<pstsdk::folder> folderlist;
folderlist.push_back(folder);
causes this compile error:
error: 'pstsdk::property_bag& pstsdk::property_bag::operator=(const pstsdk::property_bag&)' is private
(There is a lot of other veribiage about what was instantiated from what file). Here is the compile command:
g++ -c -I/usr/local/include -Iboost_1_46_1 -Ipstsdk -I/usr/local/include/mysql ostdemo.cpp
It is specifically the push_back call causing the errors - take that out and they go away. Of course
that is critical to the working of my program. Any idea what this could be? I assume it has
something to do with my compiler version or switches, but I can't figure it out. I am not much of
a c++ programmer so any help would be appreciated.
Your vector::push_back() requires that the type is copy-assignable. Obviously, your pstsdk::folder is not copy-assignable due to the assignment operator being private.
What are the requirements for a type to be placed in a vector? It depends on whether you're using pre-C++11 or C++11, plus what operations you plan to do on these types. See here:
http://en.cppreference.com/w/cpp/container/vector
Pay attention to CopyAssignable, CopyConstructible, MoveAssignable and MoveConstructible
So the case of it working with Windows as opposed to Linux:
Remember that "Windows" and "Linux" are not C++ compilers. You need to expand on this and tell us what version of the g++ compiler you're using on each OS.
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.