Why is Boost.ProgramOptions not header-only? [closed]

Question

Some boost libraries are header-only, some are not, and for various reasons etc.

Is there a specific reason/design decision why Boost.ProgramOptions is not header-only?

I'm wondering because it claims to be a "small" library in its the documentation and I don't see any system-related reason (like threads or asio).

Praline

Perhaps my answer is patronising you. Have an upvote so an expert might answer. – Barrada

I don’t know if it needs to do this, but it looks like almost all of the code is in .cpp files and it isn’t even attempting to be header-only: github.com/boostorg/program_options – Antilebanon

You might want to drop Vladimir Prus (vladimirprus.com) an email to see if he has an answer for you. – Kennakennan

I asked the same question to the developer of Boost.Serialization, there is actually no good reason for that in perspective. At the time, people were worried about code bloating and large compilations times. There was no question that any non-template code would be in cpp files. Now these problems are less serious. Once they decided to make separate compilation they abused it and it is now too hard to make it header only because of singletons and static variables, things like that. Although sometimes is possible to make it header only by copying cpp code (from source) into hpp. Want to try? – Settling

Here these is header only library to process program optiosn, it claims to have similar features as Boost.ProgramOptions: github.com/rambler-digital-solutions/raconfig . So there is no fundamental reason for not being header-only. There is also CLI11, header only, github.com/CLIUtils/CLI11/tree/v0.1 – Settling

In addition, Boost.ProgramOptions's main component is a parser (like Boost.Serialization) and parsers usually has a lot of static data (lile tables of characters or delimiter). These tends to be put in cpp files, nowadays there are other options, like constexpr strings, etc. – Settling

One of Boost's biggest parser libraries (boost.spirit) is written completely header only. So it should definitively be possible. Maybe the authors just didn't see it possible back then and now don't want to change it anymore. – Valerlan

Answer 1

Program Options claims to be small, but it turns out to be the second largest library we were building, after Regex. (It is bigger than boost Filesystem and Thread libraries.) I believe that you should be glad they're building a library for it instead of choking your project with a ton of included headers. Perhaps the author thought it would be small when he started and forgot to change the comment when it continued to grow and add features.

Hygrometry

Why was this answer down-voted? It is a very good guess and I actually completely agree with it... – Fremitus

Answer 2

Not all C++ code can be written in just headers due to one-definition-rule violations.

For example, the storage reservation for a static member of a class needs to be in exactly one translation unit (although future C++ standards may obviate that).

The original intention was for Boost to be header only, but they had to quickly relinquish that aspiration.

Barrada

Yeah, I know, looking for the specific case of Boost.ProgramOptions. – Praline

Cuz it contains such a construct, innit! – Barrada

C++17 inline variables were of course out of the question at the time, but they can be emulated with static class template members. – Poltergeist

@Quentin: Would be such a pity if boost went header only. bjam and b2 are quite a learning curve. Imagine a world where that knowledge was no longer required :-( – Barrada