Re: [boost] [all] Request for out of the box visibility support

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
> 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
>