C++ Boost: What's the Cause of This Warning

C++ Boost: what's the cause of this warning?

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. ;)

Trying to get rid of a c++ boost warning

The reason is that boost doesn't push/pop these pragmas in every file that needs data to be packed. They #include a separate file which does the push (abi_prefix.hpp), and then another (abo_suffix.hp) afterwards which does the pop.

That allows them to reuse the same #pragma pack code everywhere, which is handy as it may vary between compilers.

It's perfectly safe though. The #pragma push is followed by a pop, it's just included from a different file. So you should probably just disable that error.

Boost's is_any_of causes compile warning?

Seeing as there's no more activity around this issue I'll close this with saying that yes - this is a boost issue. It's easily reproduced with @sehe 's MCVE.
Apparently compiling boost with strict warnings and Werror flags is impossible.

As per my workaround, I had a fairly simple use-case and I've implemented my own, simple, version of split

inline std::vector<std::string> Split(const std::string &str, char delim)
{
  std::vector<std::string> out;
  std::stringstream ss(str);
  std::string item;
  while (std::getline(ss, item, delim)) {
      out.push_back(item);
  }
  return out;
}

GCC's Warning in Boost Source

Normally GCC and Clang automatically suppress warnings from headers in /usr. However, it seems that for /opt it doesn't. To tell the compiler that the boost headers should be treated as system headers, use -isystem instead of -I to add the boost headers to the include paths.

Warning C4503 when using #pragma warning around Boost includes

It seems as if it's a warning the boost guys have decided to suppress for the Visual C++ compiler.

From here:

Warning: C4503 decorated name length exceeded

Suggestions: Suppress. (Note that \boost\config\compiler\visualc.hpp includes this global > suppression...)! Suppression: #pragma warning(disable:4503)

Now for the complier. Note the following code:

#pragma warning (push, 1)
#pragma warning (disable:4503)

// C4503.cpp
// compile with: /W1 /EHsc /c
// C4503 expected
#include <string>
#include <map>

class Field{};

typedef std::map<std::string, Field> Screen;
typedef std::map<std::string, Screen> WebApp;
typedef std::map<std::string, WebApp> WebAppTest;
typedef std::map<std::string, WebAppTest> Hello;
Hello MyWAT;

#pragma warning (pop)

I just tweaked the Microsoft help example for this warning

if you put the #pragma warning (disable:4503) after the push, you get the warning. If you put it before, there are no warnings. That means the code above generates C4503 warnings, even though it was disabled.

Why does calling boost::split() give so many warnings?

The first line of the warning tells you everything, both why and how to avoid it, among other things this: To disable this warning, use -D_SCL_SECURE_NO_WARNINGS. So go to the project properties, and put _SCL_SECURE_NO_WARNINGS among predefined macros.

Boost process child with custom environment causes deprecation warning/error

Like the commenter, I'm unable to reproduce this on my system.

So we really need to know more about what tools you use to compile, and what you're compiling (versions).

That said, I think the issue can be skirted by making the Boost include a system include, e.g. with -isystem /path/to/boost or add_includes(SYSTEM /path/to/boost) and similar when using CMake.

Warnings when compiling Boost libraries in C++ Builder

add #define BOOST_THREAD_USE_LIB before including the thread.hpp.

This is what I tested:

#define BOOST_THREAD_USE_LIB
extern "C"
{
   namespace boost
   {
      void tss_cleanup_implemented( void )
      {
         /*
         This function's sole purpose is to cause a link error in cases where
         automatic tss cleanup is not implemented by Boost.Threads as a
         reminder that user code is responsible for calling the necessary
         functions at the appropriate times (and for implementing an a
         tss_cleanup_implemented() function to eliminate the linker's
         missing symbol error).

         If Boost.Threads later implements automatic tss cleanup in cases
         where it currently doesn't (which is the plan), the duplicate
         symbol error will warn the user that their custom solution is no
         longer needed and can be removed.*/
      }
   }
}
#include <boost/thread.hpp>

Then set 'Link with Dynamic RTL' and 'Link with Runtime Packages'.

This does a clean build and starts a thread properly.

Visual Studio 2012 C++ compile error with Boost Signal2

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.

Locating error in source which is boost related

@Eljay, does it have a human readable text option I could locate in the IDE? – SPlatten 43 mins ago

The thing you posted IS human readable text. It actually describes a warning with a reference to documentation. ¯\(ツ)/¯ Maybe you can just tell the compiler you don't want to receive warnings

In addition, you can use the keywords to google additional information:

C++ Boost: what's the cause of this warning?

Many libraries in addition already have a warning-suppression header (look for e.g. boost/iostreams/detail/config/disable_warnings.hpp or boost/random/detail/disable_warnings.hpp). The fact that known benign warnings "slip through" might indicate that the library needs to update their suppressions, OR you might need to upgrade your boost version.

---

Related Topics