You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I encountered this problem at work while using Beast to write a simple http client.
I;m trying to get the error code as a return value from stream.async_connect(), but I kept getting errors about ambigious overloads.
After some investigation, I discovered that asio::as_tuple(asio::use_awaitable) is valid for both RangeConnectHandler and ConnectCondition.
The overload with ConnectCondition also defaults its RangeConnectHandler argument, causing this compiler error.
Is this a bug, or is this the actual intended behaviour?
boost::asio::awaitable<void> PostRequestImplementation(std::string const host, std::string const port, std::string const target)
{
using namespace boost;
namespace ip = asio::ip;
namespace http = beast::http;
auto resolver = asio::use_awaitable.as_default_on(ip::tcp::resolver(co_await asio::this_coro::executor));
auto stream = asio::use_awaitable.as_default_on(beast::tcp_stream(co_await asio::this_coro::executor));
auto [__, results] = co_await resolver.async_resolve(host, port, asio::as_tuple(asio::use_awaitable));
auto ec = co_await stream.async_connect(results, asio::as_tuple(asio::use_awaitable));
// ERROR: Call to member function 'async_connect' is ambiguous
// basic_stream.hpp(1028, 5): Candidate function [with EndpointSequence =
// boost::asio::ip::basic_resolver_results<boost::asio::ip::tcp>, RangeConnectHandler =
// boost::asio::as_tuple_t<boost::asio::use_awaitable_t<>>, $2 = void]
// basic_stream.hpp(1132, 5): Candidate function [with EndpointSequence =
// boost::asio::ip::basic_resolver_results<boost::asio::ip::tcp>, ConnectCondition =
// boost::asio::as_tuple_t<boost::asio::use_awaitable_t<>>, RangeConnectHandler = boost::asio::use_awaitable_t<>, $3 = void]
// Below code does work, but is a bit annoying
// auto [ec, _] = co_await stream.async_connect(
// results,
// [](boost::system::error_code const &, ip::tcp::endpoint const &) { return true; },
// asio::as_tuple(asio::use_awaitable));
co_return;
}
All relevant compiler information
Compiled using gcc (Debian 12.2.0-14) 12.2.0 with C++20 and /W4
The text was updated successfully, but these errors were encountered:
The issue arises from using an executor with a default completion token in this line:
auto stream = asio::use_awaitable.as_default_on(beast::tcp_stream(co_await asio::this_coro::executor));
This adds a default value for the last parameter (the completion token), resulting in ambiguous calls because the first parameters like EndpointSequence and ConnectCondition aren't constrained. If you change stream to:
auto stream = beast::tcp_stream(co_await asio::this_coro::executor);
the issue goes away. I'll investigate if there's a way to constrain these template parameters and fix the problem.
Aha, that explains a lot, I was following one of the examples, which made them like this.
Thanks a lot for the quick help! You can close this issue then if you want :)
Unfortunately, there is no type trait for constraining ConnectCondition in Asio. Indeed, the issue also exists in Asio: https://godbolt.org/z/aqxns58n5.
Version of Beast
Boost: 1.83, Beast: 347
Steps necessary to reproduce the problem
I encountered this problem at work while using Beast to write a simple http client.
I;m trying to get the error code as a return value from
stream.async_connect()
, but I kept getting errors about ambigious overloads.After some investigation, I discovered that
asio::as_tuple(asio::use_awaitable)
is valid for bothRangeConnectHandler
andConnectCondition
.The overload with
ConnectCondition
also defaults itsRangeConnectHandler
argument, causing this compiler error.Is this a bug, or is this the actual intended behaviour?
All relevant compiler information
Compiled using gcc (Debian 12.2.0-14) 12.2.0 with C++20 and /W4
The text was updated successfully, but these errors were encountered: