1

Building with Boost-1.67.0 and VS on Windows, I get a C4702 "unreachable" warning for boost::beast::http::detail::verb_to_string(verb v), in boost/beast/http/impl/verb.ipp:

template<class = void>
inline string_view verb_to_string(verb v)
{
    switch(v)
    {   
    case verb::delete_:       return "DELETE";
    case verb::get:           return "GET";
    case verb::head:          return "HEAD";
    case verb::post:          return "POST";
    case verb::put:           return "PUT";
    case verb::connect:       return "CONNECT";
    o o o
    case verb::unknown:
        return "<unknown>";
    }

    BOOST_THROW_EXCEPTION(std::invalid_argument{"unknown verb"});

    // Help some compilers which don't know the next line is
    // unreachable, otherwise spurious warnings are generated.
    return "<unknown>";
}

The last (bottom) return "<unknown>"; was added to appease compilers not smart enough to know that the thrown exception prevents a normal return; however, that same line of code is problematic for (the smarter) Visual Studio which flags the statement as unreachable (C4702). In my case, we translate compiler warnings to errors, so it's more than simply annoying.

The following hack takes some inspiration from @DanielSeither's answer to Disable single warning error, and seems to work:

//
// Filename: boost_beast_http.hpp-no-c4702
//
// i.e. #include "boost_beast_http.hpp-no-c4702"
//
// Should appear before any other boost/beast header.
//

#if defined(OS_WIN32) || defined(OS_WIN64)

#ifndef BOOST_BEAST_HTTP_VERB_HPP
#define BOOST_BEAST_HTTP_IMPL_VERB_IPP
#include <boost/beast/http/verb.hpp>
#undef  BOOST_BEAST_HTTP_IMPL_VERB_IPP
#pragma warning( push )
#pragma warning( disable : 4702 )
#include <boost/beast/http/impl/verb.ipp>
#pragma warning( pop )
#endif

#endif

#include <boost/beast/http.hpp>

but short of patching the source code for Microsoft VC++ builds, could someone suggest a better workaround?

badfd
  • 63
  • 7
  • If it's working, what's the problem? – Passer By Apr 27 '18 at 17:48
  • It's ugly in several respects. I'm hoping someone has a cleaner, more systematic approach to this category of problem. Maybe a compilation flag of which I'm unaware: `-fno-warn-on-return-after-throw` – badfd Apr 27 '18 at 18:04
  • That sounds misguided. To fix this one place where you hate the syntax, you potentially miss a serious bug in another. – Passer By Apr 27 '18 at 18:11
  • Not misguided at all. Compiled correctly, the 'return' in a return-after-throw will never be executed, so the (non-existent/invented) flag I suggested would serve a useful purpose. – badfd Apr 27 '18 at 18:47
  • It is fixed in master and develop: https://github.com/boostorg/beast/commit/3c3f4fc52b5dd2f625ed9eeba26cb74cf5b8d693 this should have been opened as a GitHub issue rather than a StackOverflow question – Vinnie Falco Apr 27 '18 at 19:04

0 Answers0