Hi, I was reading the development section of the docs: https://www.boost.org/development/index.html And, I noticed there was nothing in the development guidelines about when to implement as headers-only vs built library. I got my own ideas of why most libraries are headers-only. But, I was wondering if someone with the historical context (someone who was here when those first libraries were developed) can share how boost got into the current shape and what new library developers should look into when deciding to go headers-only or not. I appreciate any anecdotes, guidelines, tradeoffs, thumb rules, comments on the topic. I would love to collect as much as possible here in this thread and write something to post in the development doc section in the website for future reference. Best, Damian
On 3/15/2021 7:48 AM, Damian Vicino via Boost wrote:
Hi, I was reading the development section of the docs: https://www.boost.org/development/index.html And, I noticed there was nothing in the development guidelines about when to implement as headers-only vs built library. I got my own ideas of why most libraries are headers-only. But, I was wondering if someone with the historical context (someone who was here when those first libraries were developed) can share how boost got into the current shape and what new library developers should look into when deciding to go headers-only or not. I appreciate any anecdotes, guidelines, tradeoffs, thumb rules, comments on the topic. I would love to collect as much as possible here in this thread and write something to post in the development doc section in the website for future reference.
I think this is a great topic, even if it is not directly related to Boost but more related to C++ and use of class and function templates, inline code versus out-of-line code, declarations versus definitions. In the past, when working as a consultant for various companies, I created numerous libraries for code reuse, mostly DLLs under Windows. I recall that these libraries were essentially divided by .h/.hpp header files with their declarations and .cpp source files with their definitions. It seemed natural then that the .cpp files would be compiled into object files and those object files would become a DLL with its own API documentation based on header file declarations/constructs. With templates, of course, the line between declarations and definitions is blurred since template declarations/definitions are rarely divided between source and header files. Of course any library can be a mixture of templates, plain classes, functions and whatever. But in Boost entire libraries are just templates, especially class templates, and this very often leads to header-only libraries. But I admit I would love to hear from others about this issue of when to create purely header-only libraries versus shared ( or static ) libraries, or of shared ( or static libraries ) with a mixture of header-only code. So hopefully others can offer their wisdom and experience in this area.
Best, Damian
Gesendet: Montag, 15. März 2021 um 12:48 Uhr Von: "Damian Vicino via Boost"
Hi, And, I noticed there was nothing in the development guidelines about when to implement as headers-only vs built library.
Well, I've no idea about the historical context, but one obvious point (that I still feel the need to make) is that many boost libraries are very heavily templated (and/or constexpr) and as such have to be header only anyway. Of course, you often can put part of the functionality into a regular function that you then implement in a cpp file, but if 90% of your code is in headers already, there is usually little benefit in putting the remainign 10% into a separate source file and force the user to handle the increased complexity of building the lib (in a compatible manner). In an ideal world, c++ would quickly adapt modules and the recommendation for future contributors would be to just use modules, but thats not really a practical suggestion. Best Mike
Best, Damian
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Mar 15, 2021 at 9:06 AM Mike via Boost
...
There's a new sheriff in town, an alternative to the traditional
paradigms of header-only and pre-built library. I call it "included
source." It offers the fast compilation of a pre-built library with
the ease of integration of a pre-built library. It doesn't require or
depend on any particular build system. Credit to Christopher Kohlhoff
for using this technique in Boost.ASIO, which I copied in my projects.
Boost.JSON offers this method as an alternative to building a static
or share library. It works like this. Simply place the following line
in exactly one new or existing source file in the program where you
want to use Boost.JSON:
#include
On Mon, Mar 15, 2021 at 9:42 AM Vinnie Falco
It offers the fast compilation of a pre-built library with the ease of integration of a pre-built library.
I meant to say: "It offers the fast compilation of a pre-built library with the ease of integration of a header-only library" Thanks
participants (4)
-
Damian Vicino -
Edward Diener -
Mike -
Vinnie Falco