Subject: Re: [boost] [beast] How do I select un-DEPRECATED interfaces?
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2018-06-04 01:52:26
On Wed, May 30, 2018 at 9:25 AM, Brian Kuhl via Boost
> Iâve gotten a clean compile of Beast...
I'm not sure I follow. Beast is header-only, there's no library to
compile. Do you mean that you were compiling the tests, or examples?
Or perhaps you mean that you were able to get your own code to
> #define BOOST_BEAST_ALLOW_DEPRECATED
Defining this macro lets your existing code which depends on
deprecated Beast features to continue to compile. I should point out
that the interfaces which were deprecated are pretty obscure, you have
to be quite the advanced user to get this warning. In particular,
construction of user-defined instances of BodyReader or BodyWriter
concepts using a message instead of a header and body is deprecated
(the solution is to modify your type to construct with a header and
Instructions for fixing affected code, along with a list of deprecated
interfaces, may be found in the Release Notes section of the
> #define BOOST_COROUTINES_NO_DEPRECATION_WARNING
Beast does not use coroutines. However, if your own code wants to call
Beast asynchronous operations using Boost.Asio coroutines that is
certainly possible. Either way, the macro
BOOST_COROUTINES_NO_DEPRECATION_WARNING affects only your code and not
You can safely ignore warnings about deprecated coroutine interfaces.
If the classic Boost.Coroutine (which supports pre-C++11 compilers)
ever truly goes away in a particular Boost version, then Boost.Asio
will almost certainly have been updated to no longer need it.
> But Iâm having trouble locating the logic thatâs choosing these deprecated
> interfaces for me?
I'm not sure what you mean by "logic that is choosing deprecated
interfaces." The interfaces which are deprecated in Beast have to be
called by your code. If you aren't relying on deprecated Beast
interfaces, you won't get any deprecation warnings.
I hope this helps!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk