Subject: Re: [boost] [all] Request for out of the box visibility support
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-08-20 20:45:17
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_at_[hidden]> wrote:
> I think a better solution is to remove link libraries where possible. For
> 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
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.
> - Jim
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk