|
Boost : |
From: Marcelo Zimbres Silva (mzimbres_at_[hidden])
Date: 2022-03-31 16:00:34
Hi Ruben,
I have had a look into your library and some questions arise
> https://anarthal.github.io/mysql/mysql/ref/boost__mysql__resultset/async_read_all.html
> The handler signature for this operation is void(boost::mysql::error_code, std::vector<boost::mysql::row>).
> etc.
Having a std::vector in the signature of the completion handler is
unusual in ASIO. In general large objects should be passed as
parameters in the async operation e.g. socket::async_read gets a
dynamic_buffer which is a lightweight view to storage.
Additionally, there is not support for custom allocators. That
wouldn't be a big problem to me if I could reuse the same memory for
each request but the interface above prevents me from doing so.
> https://anarthal.github.io/mysql/mysql/ref/boost__mysql__connection/async_query/overload1.html
> The handler signature for this operation is void(boost::mysql::error_code, boost::mysql::resultset<Stream>)
Hier the completion handler is returning an io object i.e.
boost::mysql::resultset, which is also unusual as far as I can see.
Does that play nice with executors? I would prefer having the
completion handler return config parameters with which I can
instantiate a boost::mysql::resultset myself in my desired executor.
> https://anarthal.github.io/mysql/mysql/ref/boost__mysql__connection.html
I don't see a reason for this class, or at least I fail to see what
state does the mysql protocol imposes on you that would justify this
class. I would prefer free funcitions much more here, for example, in
the same way as beast::http::async_read.
> https://anarthal.github.io/mysql/mysql/ref/boost__mysql__value/get_std_optional.html
> https://anarthal.github.io/mysql/mysql/ref/boost__mysql__value/get_optional.html
Sounds also unusual to have two member functions for the different
versions of optional.
Regards,
Marcelo
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk