On 8/19/18 9:31 AM, James E. King III via Boost wrote:
On Sun, Aug 19, 2018 at 7:48 AM Antony Polukhin via Boost < boost@lists.boost.org> wrote:
I think a better solution is to remove link libraries where possible. For example in date_time there isn't much of a case to keep the linked library. If we look at the issue it causes like https://github.com/boostorg/date_time/pull/34, one of the solutions to that issue of visibility is to remove the link library entirely. I'd have to recommend all libraries attempt to become header-only to avoid these issues. Obviously that won't work for all libraries, but it's possible for a number of them. I opened https://github.com/boostorg/date_time/issues/85 to track that for date_time.
TL;DR; The appeal of using header only libraries is sign that we have bigger problems not being addressed. Basically this amounts to deprecating the separate compilation model that is a historical feature of C++. In my view it's an essential feature. Many complain of compile times that are "too long" for their 1000000 line programs. More than anything this is an indicator that their code hasn't been factored into separately compilable modules. Not that I'm totally unsympathetic. The C++ separate compilation model was extended to shared libraries in an ad hoc way by each vendor. Now we have issues with symbol visibility and ABI compatibility. The tools vendors havn't really addressed this and so C++ programs are a pain to configure and build. It's also unwieldy to incorporate library code and especially pre-compiled modules. Just using header only - solves the major convenience problems - but the build doesn't scale anymore creating 1,000,000 compilations. Now we're looking a adding concepts, contracts and modules. I'm really concerned that C++ may collapse under it's own weight. What is really needed is for someone to step back and and re-address the issues of ODR, visibility, ABI compatibility and versioning, build tooling and anything else that ripples to. It's huge task. C++ growth is O(n^2) where n is the number of features added. Basically, C++ has become a victim of it's own success. In the past, this has often resulted in new programming languages. But now I see the C++ universe as being too big for this. Robert Ramey
- Jim
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost