So the 4251 warning is a serious base of at least microsoft's compiler. Essentially, any time you use a template class or non-dllexport class anywhere in the header definition you will get this warning. Better yet, there are numerous classes in stl (like map) where you can't even get rid of this error, period.
My problem is, is that for a specific class, the "#pragma warning(disable: 4251)" just flat out isn't working. It is working everywhere else but here.
DelWestInspectionProgram.cpp
#include "stdafx.h"
#pragma warning(disable: 4251)
...
Output Log:
E:\svn\VisionNow\VisionSuite\VI.Inspector.ImageProcessing.Common\BIImage.h(79): warning C4251: 'BIImage::_data' : class 'boost::shared_array<T>' needs to have dll-interface to be used by clients of class 'BIImage'
6> with
6> [
6> T=unsigned char
6> ]
6>E:\svn\VisionNow\VisionSuite\VI.Inspector.ImageProcessing.Operators\BIImageOperator.h(25): warning C4251: 'BIImageOperator::_savePath' : class 'std::basic_string<_Elem,_Traits,_Ax>' needs to have dll-interface to be used by clients of class 'BIImageOperator'
6> with
6> [
6> _Elem=char,
6> _Traits=std::char_traits<char>,
6> _Ax=std::allocator<char>
6> ]
Any help would be greatly appreciated.
From my own experience there are two issues: when it is a DLL import and when it is a DLL export.
Where it is the dllexport, Microsoft seems to ignore the #pragma warning but this is just the one project so easy to put into the compiler settings to ignore this warning. I found if you put it there, Microsoft does not issue the warning.
Where it is the dllimport, i.e. the file using your header. I found there Microsoft does not ignore the pragma and does not issue the warning, so putting it in both places will fix your issue.
My guess is that the 79 projects that suppress the warning fine are those ones that are not the DLL itself.
The warning is probably there for a reason, that being that if your client library is using a different version of boost, or even a different compiler setting, it might break.
As far as I know, some errors cannot be disabled. It is that way with the Linker. Therefore I would assume it is the same way with some compiler too. But in general I would put it inside your stdafx.h file, or at least before it. Putting it after doesn't guarantee anything, especially since we can't see your code.
[EDIT]
On the other hand that is a serious warning that I would fix if I were you and not just ignore it. If you search here on stack overflow you will find some great discussions about why it is a problem.
Related
Something is very wrong with strings. I have been using them for weeks without issue, but halfway through Monday, I started having strange issues:
[Clang IntelliSense] Error: variable has incomplete type 'std::string'
whenever I try to make a string. similar errors occur when I try wstring and ostringstream, but not stringstream. initializing std::string* s also works fine but s->append(...) results in"member has access into incomplete type 'std::string'"
This all came about because visual studio (VS) was all of a sudden unable to find some #includes that I have had for weeks, including some standard libraries (don't remember which because...). I solved that by having VS search for the correct files and it found some files (unsure if they're the same as before or different) so it no longer has an issue with the #include statements but now I have this issue.
I had been using <string.h> fine for weeks. while researching this issue, I read that <string.h> is the wrong file to use so I've tried #include <string> but there is no difference. I've since tried <strings.h> and <cstring> but no difference there either.
I checked out my external dependencies and string.h has dozens of errors, which I thought is weird because it's a standard file that I haven't touched.
I'm using VS2015, GNU make, and I see Clang IntelliSense but I also see some g++ here so I'm not sure what compiler it's actually using. also using visualGDB 5.3. let me know if I forgot anything.
#include <iostream>
#include <string>
#include <sstream>
int main(int argc, char *argv[])
{
std::string message = "uncomment";
...
message
is the part that is highlighted as having an issue (incomplete type)
std::wstring wideMessage;
also incomplete type
expected results: no problems like the past few weeks. I was able to declare, initialize, append(), whatever
actual results: can't compile/debug
errors: variable has incomplete type 'std::string' variable has incomplete type 'std::wstring' no matching constructor for initialization of 'std::ostringstream'
I see many similar issues here, but all the issues have to do with forward declaration and I don't see what that has to do with this. I'm not having any issues with classes, structs, or functions; even declaring a variable in main() is problematic
edit: based on this answer, it is likely using VC++ 14.0 as a compiler but I do not know how to tell for sure
edit 2: error message:
1> VisualGDB: Sending 45 updated source files to build machine...
1> VisualGDB: Run "make CONFIG=Debug" in directory "/tmp/VisualGDB/c/Users/pthien/VS/Whatever/Whatever" on pthien#buildserver (SSH)
1> /opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 --sysroot=/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi -ggdb -ffunction-sections -O0 -std=c++11 -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 --sysroot=/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi -ggdb -ffunction-sections -O0 -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include -I/opt/googletest-master/googletest/include -I/opt/boost_1_61_0 -I../../cereal/cereal-1.2.2/cereal-1.2.2/include -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/websocketpp-master -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/websocketpp -I/opt/curl-7.54.0 -I/opt/boost_1_61_0/boost -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/easywsclient-master -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/uWebSockets-master -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/c++/4.9.2/experimental -I/opt/boost_1_61_0/boost/tr1/tr1 -I/opt/boost_1_61_0/tools/build/src/engine -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/c++/4.9.2 -I/opt/curl-7.54.0/include -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/cereal -I/opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.2/include-fixed -I/opt/boost_1_61_0/boost/compatibility/cpp_c_headers -I"../../../../../Program -IFiles -I(x86)/Microsoft -IVisual -IStudio -I10.0/VC/crt/src" -I"../../../../../Program -IFiles -I(x86)/Microsoft -IVisual -IStudio -I14.0/VC/include" -I/opt/poky/1.8/sysroots/cortexa8hf-vfp-neon-poky-linux-gnueabi/usr/include/c++/4.9.2/arm-poky-linux-gnueabi -DDEBUG -c Whatever.cpp -o Debug/Whatever.o -MD -MF Debug/Whatever.dep
1> C:\Users\pthien\AppData\Local\VisualGDB\RemoteSourceCache\buildserver\0008\include\wchar.h(459,20): note : 'wcstold'
1> extern long double wcstold (const wchar_t *__restrict __nptr,
1> ^
1> Whatever.cpp: In function 'int main(int, char**)':
1>C:\Users\pthien\VS\Whatever\Whatever\Whatever.cpp(138,47): error : 'strlen' was not declared in this scope
1> size_t request_len = strlen(webSocketRequest);
1> ^
1> Makefile:160: recipe for target 'Debug/Whatever.o' failed
1> make: *** [Debug/Whatever.o] Error 1
1> -------------------------------------------------------------
1> Command exited with code 2
1> Executable: make
1> Arguments: CONFIG=Debug
1> Directory: /tmp/VisualGDB/c/Users/pthien/VS/Whatever/Whatever
1>VisualGDB : error : Command-line action failed
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.MakeFile.Targets(37,5): error MSB3073: The command ""C:\Program Files (x86)\Sysprogs\VisualGDB\\VisualGDB.exe" /build "C:\Users\pthien\VS\Whatever\Whatever\Whatever.vcxproj" "/solution:C:\Users\pthien\VS\Whatever\Whatever.sln" "/config:Debug" "/platform:Win32"" exited with code 1.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
This is about 10% of the output, including the beginning and the end. What's weird is the issue with strlen(). It is not underlined in the IDE, so I had no idea there was an issue with it. It makes sense because I commented out the #include for <string.h>and <cstring> and strlen() is in one of those.
If you copied your code exactly from what you have, I see two declarations of argc in your definition of main. Your compiler should definitely be throwing errors about that. Perhaps your compiler delays the read error until you declare a std::string in main? (I've had a compiler throw an error several lines after the actual error for something seemingly unrelated.) So, you may have fixed the error in having a bad file path, but perhaps your bad definition of main throws your compiler off.
Now, if that didn't work, you mentioned seeing a bunch of compilers being used. If you see a particular compiler throwing that error, then you might want to separately update said compiler. The functionality of compilers is modular, so you can pick and choose which compiler you use for which step of the compilation. VS is probably doing this to get what it figures is the best result. Sometimes compilers carry with them the files they want to use, thus updating (or even un/reinstalling) the compiler should fix the files that it carries with it. (Windows likes to do everything for you, so you might actually mess something up if you try to update the parts separately. That was always my experience, anyway. But, I haven't used Windows in well over a year, so that may have changed.)
If that still doesn't fix it, you may have to un/reinstall VS. I will admit to knowing nothing about VS, as I use Emacs to edit and Makefile/g++ to compile. My guess, however, is VS may carry all the compilers and files it needs with it, so an update or un/reinstall will (hopefully) fix your issue.
managed to avoid this issue, but probably not solve the still-unknown underlying issue, by removing an unused library from my list of directories and then reloading all directories. I'm not convinced anything was solved because reloading directories gives random results. sometimes it fixes issues and sometimes it causes new ones. Just yesterday, I reloaded and it was then unable to find system.h and time.h (don't remember the names). I was troubleshooting that but the issue disappeared a few hours later. anyway
I posted a follow-up question here
I have an application that uses numerous templates and template specializations, and during MSVC compilation many messages are output showing how the templates are being compiled. This makes for an incredibly difficult time finding an actual compilation error. These messages are not output when the application is compiled on Linux using g++.
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\map(382)
: see reference to function template instantiation 'std::pair<std::_Tree_iterator<std::_Tree_val<std::_Tree_simple_types<std::pair<const _Kty,_Ty>>>>,bool> std:
:_Tree<std::_Tmap_traits<_Kty,_Ty,_Pr,_Alloc,true>>::insert<std::pair<std::string,uint64_t>>(_Valty &&)' being compiled
with
[
_Kty=std::string
, _Ty=size_t
, _Pr=std::less<std::string>
, _Alloc=std::allocator<std::pair<const std::string,size_t>>
, _Valty=std::pair<std::string,uint64_t>
]
Is there a way can I suppress these more or less useless messages? Or possibly lower the verbosity setting? I've tried looking at link but I'm not sure if there is a flag that relates to the messages I'm seeing.
The message is related to an warning (or error) with a specific template instantiation. If it is a warning, you could suppress it (via #pragma warning, or project settings), and this message would also go away. Or, you could fix the cause of the warning. There is no way to suppress this message without also suppressing the warning, because without it, the warning doesn't make much sense.
The following code issues a warning:
boost::gil::rgb8_image_t img(10, 10);
boost::gil::png_write_view("TenByTen.png", view(img));
when compiled with VS 2010 under 64 bit. It says:
\boost\gil\extension\io\png_io_private.hpp(341): warning C4244: 'argument' : conversion from '__int64' to 'png_uint_32', possible loss of data
\boost\gil\extension\io\png_io.hpp(202) : see reference to function template instantiation 'void boost::gil::detail::png_writer::apply<View>(const View &)' being compiled
with
[
View=boost::gil::image_view<boost::gil::rgb8_loc_t>
]
main.cpp(20) : see reference to function template instantiation 'void boost::gil::png_write_view<boost::gil::image_view<Loc>>(const char *,const View &)' being compiled
with
[
Loc=boost::gil::rgb8_loc_t,
View=boost::gil::image_view<boost::gil::rgb8_loc_t>
]
It seems quite obvious that in apply() the call to png_set_IHDR() should give a png_uint_32, but view.width() seems to be a signed __int64 (maybe a ptrdiff_t).
Does anybody know what i could do about it?
I guess that boost:gil is meant to work under 64 bits.
I use boost 1_50.
It seems that the specific issue is known from (at least) Boost v1.35 (e.g. http://objectmix.com/c/733997-how-use-graphics.html#post2586573).
Checking Boost trac database I see similar tickets for other modules but nothing for GIL.
Probably the best thing is open a new ticket.
Meanwhile, since it doesn't seem "catastrophic", you could wrap the #include(s) in this way:
#ifdef _MSC_VER
# pragma warning(push)
# pragma warning(disable: 4244) // Perhaps also 4100, 4127, 4512
// GIL headers
# pragma warning(pop)
#endif
See also How to: Enable and Disable Code Analysis for Specific C/C++ Warnings
(with clang/gcc you have the -isystem switch, but I don't think Visual Studio lets you differentiate between application/header files)
I have a simple C++ with Boost like this:
#include <boost/algorithm/string.hpp>
int main()
{
std::string latlonStr = "hello,ergr()()rg(rg)";
boost::find_format_all(latlonStr,boost::token_finder(boost::is_any_of("(,)")),boost::const_formatter(" "));
This works fine; it replaces every occurrence of ( ) , with a " "
However, I get this warning when compiling:
I'm using MSVC 2008, Boost 1.37.0.
1>Compiling...
1>mainTest.cpp
1>c:\work\minescout-feat-000\extlib\boost\algorithm\string\detail\classification.hpp(102) : warning C4996: 'std::copy': Function call with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators'
1> c:\program files (x86)\microsoft visual studio 9.0\vc\include\xutility(2576) : see declaration of 'std::copy'
1> c:\work\minescout-feat-000\extlib\boost\algorithm\string\classification.hpp(206) : see reference to function template instantiation 'boost::algorithm::detail::is_any_ofF<CharT>::is_any_ofF<boost::iterator_range<IteratorT>>(const RangeT &)' being compiled
1> with
1> [
1> CharT=char,
1> IteratorT=const char *,
1> RangeT=boost::iterator_range<const char *>
1> ]
1> c:\work\minescout-feat-000\minescouttest\maintest.cpp(257) : see reference to function template instantiation 'boost::algorithm::detail::is_any_ofF<CharT> boost::algorithm::is_any_of<const char[4]>(RangeT (&))' being compiled
1> with
1> [
1> CharT=char,
1> RangeT=const char [4]
1> ]
I could certainly disable the warning using
-D_SCL_SECURE_NO_WARNINGS
but I'm a bit reluctant to do that before I find out what's wrong, or more importantly if my code is incorrect.
It is nothing to worry about. In the last few releases of MSVC, they've gone into full security-paranoia mode. std::copy issues this warning when it is used with raw pointers, because when used incorrectly, it can result in buffer overflows.
Their iterator implementation performs bounds checking to ensure this doesn't happen, at a significant performance cost.
So feel free to ignore the warning. It doesn't mean there's anything wrong with your code. It is just saying that if there is something wrong with your code, then bad things will happen.
Which is an odd thing to issue warnings about. ;)
You can also disable this warning in specific headers:
#if defined(_MSC_VER) && _MSC_VER >= 1400
#pragma warning(push)
#pragma warning(disable:4996)
#endif
/* your code */
#if defined(_MSC_VER) && _MSC_VER >= 1400
#pragma warning(pop)
#endif
If you feel safe about disabling this error:
Go to the properties of your C++ project
Expand the "C/C++"
Highlight "Command Line"
Under "Additional Options" append the following to any text that might be in that box
" -D_SCL_SECURE_NO_WARNINGS"
The warning comes from Visual Studio's non-standard "safe" library checks introduced starting with MSVC 8.0. Microsoft has identified "potentially dangerous" APIs and has injected warnings discouraging their use. While it is technically possible to call std::copy in an unsafe way, 1) receiving this warning does not mean you are doing so, and 2) using std::copy as you normally should is not dangerous.
Alternatively, if you use C++11 and don't want to turn off warnings, you have the painful option of replacing
boost::is_any_of(L"(,)")
with the following lambda expression
[](wchar_t &c) { for (auto candidate : { L'(', L',', L')' }) { if (c == candidate) return true; }; return false; }
You can also possibly pack that into a macro
Go to the properties of your C++ project
Expand the "C/C++"
Advanced: Disable Specific Warnings: 4996
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.