Re: [boost] [Beast] Questions Before Review

Subject: Re: [boost] [Beast] Questions Before Review
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-25 21:36:05

> Template Meta-programming Based Design instead of classic Object Oriented Design
> ----------------------------------------------------------------------------------------------------------------
> I see that almost every object there is some kind of template object.
> 
> It almost mimics the API of Boost.Asio which on its way has its limitations.
> I remember I needed to implement FastCGI over TCP and Unix domain sockets
> virtually leading to same code besides some initial bind - and it required to
> create the entire parser using template programming because the socket itself
> was template object different for UNIX and TCP.
> 
> I have strong feeling that lots of stuff can actually be done using classic OOP.

This is by far one of the most annoying things I find with the ASIO API
design, and it's one of my strongest regrets that that design choice is
entering the standard. I can see why it seemed like a good idea back in
the day, but it's an obvious API design mistake now.

Thanks to my experience with ASIO, both AFIO v1 and v2 avoid the
templating of objects and APIs like the plague. It's totally unnecessary
in C++ 11, and perhaps even in C++ 98.

Where you need to consume or produce arbitrary scatter-gather buffers,
use gsl::span<T> or equivalent. AFIO v2 has a really simple,
non-template, yet just as powerful scatter-gather buffer design as ASIO
yet without using a single template. It's all thanks to gsl::span<T>
which takes care of the container adaptation for you.

I'm very proud of that part of AFIO v2, and I'd strongly recommend all
new code needing scatter-gather buffers copy that approach rather than
copying ASIO, whose scatter-gather buffer support is way over wraught
and over engineered for what is needed.

The other reason why ASIO probably felt it needed to template everything
is for arbitrary user supplied completion handlers. Yet in AFIO v2 I've
reduced that to a single common shared template which (cleverly if I do
say so myself) performs the sole memory allocation anywhere in AFIO v2
where we allocate the platform dependent storage for the async
scatter-gather i/o alongside storage for the completion handler in a
single malloc() call. This is done at the front of the async API so the
rest of the API implementation then works with that type erased
instance, allowing it to live in a precompiled DLL, and eliminating
templates for almost all of the implementation.

Now I haven't looked at BEAST yet, and BEAST is not ASIO, it's not as
low level, and it may need to work with custom strings, or
discontinuously stored lumps of HTTP data, so I certainly can see that
char iterators are going to get used a lot, and those imply templates.
That said if everything is templatised I would struggle to see the
motivation. We'll see when the review begins.

BTW Vinnie I assume BEAST works just fine with non-header ASIO, it might
be worth doing a quick benchmark to see how much of your compile times
are ASIO and how much BEAST. I would imagine it will come up.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/