Boost logo

Boost :

From: degski (degski_at_[hidden])
Date: 2020-03-08 11:48:09

On Sat, Mar 7, 2020, 8:40 PM Vinnie Falco via Boost <boost_at_[hidden]>

> On Sat, Mar 7, 2020 at 1:05 PM Edward Diener via Boost
> <boost_at_[hidden]> wrote:
> > Please stop with this mantra of library X not depending on any other
> > Boost library and reinventing constructs offered by other Boost
> > libraries ( or elsewhere ). It is not the way most programmers create
> > library software.
> I'm not saying that this applies to all libraries. Having every
> library invent every wheel is clearly not sustainable. But neither is
> introducing a dependency on Boost just because you want to call
> boost::exchange or because you want the BOOST_NODISCARD macro.
> The decision on whether to introduce a dependency should never be
> automatic one way or the other. It should be a carefully considered
> choice which balances the costs against the benefits. Now it just so
> happens, for JSON, URL, and ZLib, this balance is obviously in favor
> of having no dependencies. These libraries make sense as "leaf"
> libraries (terminal nodes in the directed acyclic graph of
> dependencies).
> Although it is irrational, there are many who view Boost as "too big"

Several GB installed is large and not irrational! On the other hand, the
use of c++17 with the oldest compiler, barely working, is irrational.

or having "too much legacy code" or whatever. As JSON libraries are in
> high demand, there's value in ensuring that my library has no
> dependencies. This equation changes depending on the library of
> course.
> --
> My advice on requiring C++17 for standalone versions of libraries is
> actually not applicable to deflate, since deflate doesn't need
> std::optional or std::string_view (or their Boost equivalents). A
> standalone version of deflate could and should require only C++11.
> Thanks
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at