On Sat, Oct 31, 2026 at 12:00 AM Reza Jahanbakhshi via Boost < boost@lists.boost.org> wrote:
Compile time and bloat: those should be measured, not assumed. Compile time I'm already working on (see my other mail).
I'll explain it all starts with ASIO. For example in ASIO Unix domain socket and TCP sockets are two separate class that share only "API" but if you want to use them both in same class you need templates to use them Example fastcgi/ scgi connection that work over both but can't actually be implemented over direct ASIO objects without templates. Same for SSL and TCP sockets. If I create a large class that handles communication there is no business whatsoever to have tcp and ssl sockets as template classes. It is the biggest design flaw of ASIO and related libraries. As an early adopter of boost.asio for some of the projects where a tiny networking part took 80% of compilation and in another required me to wrap the networking object into classic abstractions to support two different types of"streams". I'm not going down this road again. Now consider that any serious web service project contains a huge amount of business logic. Do you really want to have it header only? It isn't only a question of compilation time or code bloat - it is a question of design. For example in one of my open source astronomy /astrophotography projects openlivestacker - I use web UI that communicates with complex business logic backend that does image processing, algorithms and communicates with web ui via REST, sends video stream (mjpeg), real time updates via server sent events and more and all is in a classic library/framework that supports way-way more web0-development essential tools that beast even thinks to provide) Do you think I would ever touch a header only library for RESTful API implementation? While template metaprogramming is an amazing technique. it is heavily abused in ASIO and Beast. My $0.02