10

I am using Visual Studio 2012 Ultimate with the following Boost Signals2 code: at https://github.com/cfobel/boost_signals2/blob/master/hello_world_0.cpp It generates the following error: 

c:\program files (x86)\microsoft visual studio 11.0\vc\include\xmemory(348): error C4996: 'std::_Uninitialized_copy0': 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 11.0\vc\include\xmemory(333) : see declaration of 'std::_Uninitialized_copy0'
1>          c:\libraries\boost_1_52_0\boost\signals2\detail\auto_buffer.hpp(192) : see reference to function template instantiation '_FwdIt std::uninitialized_copy<I,boost::variant<T0_,T1>*>(_InIt,_InIt,_FwdIt)' being compiled

Is this code not compatible for Visual Studio 2012 C++? Is it still safe to use? Lastly, how do I make the changes as suggested? Thanks

heavy rocker dude
  • 2,271
  • 8
  • 33
  • 47

1 Answers1

11

C4996 is a warning about using a function that has been marked deprecated. Since you're seeing it as an error, maybe you have the Treat Warning as Error (/WX) option enabled?

The way to disable this one is described in the error message itself. Add the _SCL_SECURE_NO_WARNINGS symbol to the project's preprocessor definitions.

Praetorian
  • 106,671
  • 19
  • 240
  • 328
  • 5
    Very helpful answer but didn't touch on *"Is it still safe to use?"*. In other words, what about boost::signals2 is causing this warning and should people be concerned about it? – sgryzko Oct 09 '15 at 09:37
  • 2
    @sgryzko There is no general answer to *is it safe*, it depends on the code in question. Does the code have a bug that might result in buffer overflow? If yes, then the MSVC functions might be better. If no, then `std::uninitialized_copy` is absolutely safe to use. These warnings are just about impossible to avoid in any code you want to be able to compile on multiple compilers, because MSVC will even complain about things like `std::copy` (it wants you to use `std::_Copy_s`). – Praetorian Oct 09 '15 at 16:16
  • @sgryzko and Heavy-Rocker-Dude...Did either of you ever resolve this problem? I am having the same issue now: just converted my VS2010 project using boost::signals to VS2013, and this warning is appearing everywhere. I do NOT want to be turning off warnings...I want code to properly compile warning-free. Any ideas? Thx in advance. – David Carr Mar 23 '16 at 00:26
  • 1
    @DavidCarr You could surround `#include ` with `#pragma warning push|pop` directives to suppress these warnings for that code only. Or I guess you could start editing the Boost headers to use the versions of these functions that MSVC wants you to use. – Praetorian Mar 23 '16 at 02:05
  • @Praetorian Thx. Yeah I actually tried that as noted here http://stackoverflow.com/questions/1301277/c-boost-whats-the-cause-of-this-warning with no success, both around declarations of signals and your suggestion around the #include. I couldn't get either to supress the warnings (but quite possible my error). I can see from your post on my thread http://stackoverflow.com/questions/36168606/upgrade-to-boostsignals2-in-vs2013-results-in-c4996-warnings and digging into boost tickets that very likely no other choice other than disabling. – David Carr Mar 23 '16 at 22:12
  • @DavidCarr I didn't actually try the `#pragma`, so I don't know if it works. That's typically how you work around such warnings, but I also saw some mentions of how MSVC's stdlib headers reset warning levels, so your `#pragma` gets overridden. – Praetorian Mar 23 '16 at 22:49
  • 3
    @Praetorian: Annoyingly, the warnings from MSVC likely won't get suppressed if you just wrap the boost headerin `#pragmas` , as it blames `xmemory` later on at the template instantiation site, and that has typically been brought in by an earlier import without the pragma wrappers. It quickly devolves into a game of whack-a-mole. – Edward Kmett Aug 10 '16 at 22:15