Re: [boost] [beast] Request for Discussion

Subject: Re: [boost] [beast] Request for Discussion
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2016-10-01 21:07:16

On Sat, Oct 1, 2016 at 8:58 PM, Paul Fultz II <pfultz2_at_[hidden]> wrote:
> Well, cmake should install the library, even its header-only. It should also provide
> cmake packaging and/or pkg-config to help with linking against the library and its
> dependencies. I do this in my libraries and could send you a pull request.

Uhh...err... okay, I have to admit - I've been a Windows user for
quite a long time. And Windows was born with a handicap - there's no
well defined place to put libraries and header files. So I'm behind
the curve on having CMake "install" the library (what would that even
mean for Windows?)

But, its an interesting coincidence, someone already raised this point:
https://github.com/vinniefalco/Beast/pull/98

If you want to submit a pull request for the install functionality, I
think that would be great.

> But I do wonder if it should be header-only.
> Is it that heavily templated that `.cpp` files don’t make sense?

Well, yes. The algorithms for serializing and parsing messages are
generic, accepting any object that meets the type requirements. The
WebSocket stream can wrap any object that meets the requirements. This
lets the same code work both for plain connections and SSL
connections. Or use your own socket class if you want.

On a related point, header-only libraries are more convenient. They
require less configuration and mostly "just work." The first thing
people ask about non-header only libraries in a formal review is "Why
isn't this header-only?"

>> As far as linking goes, you should only need Boost.System (for error_code).
>
> Oh, so it doesn’t use Boost.Asio either?

It "uses" Boost.Asio, but since Asio is also header-only, there is
nothing to link with. However, Boost.Asio also requires Boost.System
for error_code (unless you fiddle with some macros).

Thanks