Re: Boost.Charconv review runs January 15th - 25th, 2024

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2024-01-25 13:25:56

On Thu, Jan 25, 2024 at 5:14 AM Ruben Perez <rubenperez038_at_[hidden]> wrote:

> I am completely with you

\phew... glad to hear it :) I was worried I was going out on a limb.

> If I happen to build a libboost_mysql.so binary, which version of
> Boost.Asio should I use? It will make my library compatible only with
> that version.
>

I forgot about this, and now that you mention it I will have to study my
new libraries (Http.Io and Websocket.Io) to figure out how much can be
compiled separately. The answer to your question is simple though: any code
whose compilation would be affected by Asio's configuration macros must
remain in headers. This means that the amount of code that is compiled into
the static or shared library is going to be small. My approach for tackling
this is to break up my libraries into two parts. A "protocol" library (also
called "sans-io": https://sans-io.readthedocs.io/how-to-sans-io.html) which
is fully compiled and an "i/o" library which uses Asio and the protocol
library. The io library is still compiled but there is more header-only
material. I strive to minimize the amount of I/O-specific code. This is
process is more disciplined by having the protocol library be physically
separated.

This is currently a hard dependency, because even in plaintext mode,
> the protocol mandates some hashing. B2 openssl package provides far
> less heuristics than CMake's, specially for Windows. My users would
> need much more effort to build than what's needed currently.
> Additionally, there's currently a limitation in boost_install for
> depending on OpenSSL.
>

Okay well it sounds like your library is already not "header-only" in
practice... LOL. If you require linking to OpenSSL then you are paying all
the costs of header-only development without getting the full benefits. Let
me make this clear:

* We (C++ library authors collectively) MUST make OpenSSL easy to install,
with NO friction for users

No more babysitting, mollycoddling, or infantilizing users, and no more
shirking our responsibility. OpenSSL is a key piece of network technology;
we need to tackle it head-on, tame it, and make sure that anyone who needs
to reach for it in their project can do so without hassle.

Thanks