Boost logo

Boost :

Subject: Re: [boost] Curiousity question
From: Oswin Krause (Oswin.Krause_at_[hidden])
Date: 2016-10-13 11:47:39

On 2016-10-13 17:09, Vinnie Falco wrote:
> On Thu, Oct 13, 2016 at 10:54 AM, Edward Diener
> <eldiener_at_[hidden]> wrote:
>> ...even when you have Boost you might prefer the C++ standard
>> equivalent
>> to avoid the Boost dependency.
> There is a greater cost to using Boost types over their C++
> equivalent. They often differ in small ways. boost::optional,
> boost::posix_time, and boost::shared_ptr come to mind, there are
> others.
> When writing code you can assume that a reader will know and
> understand C++ standard library types (since they are... standard).
> The same cannot be said about the corresponding Boost types.
> Admittedly this difference is sometimes slight but it is still
> present.
> For this reason, a standard library type almost always has an
> advantage even when the Boost type offers improved functionality;
> standard library types are what all C++ programmers know.

Thanks Vinnie,

you are writing much better I have been trying to write. I also see a
bigger problem regarding the "bigger outlook". As a library maintainer
of a boost library, would I rather have to support the boost type or the
std type? It would be weird if my library would depend on
std::posix_time but could not work with boost::posix_time. Sometimes,
because of the subtle change in semantics, I have to choose one. Giving
your argument I would choose std::posix_time which would make my own
library semantically incompatible to boost. If I follow the ideal of
"everything in boost should work together", then I would not fit well in
the C++11 world any more.

There was a while back a longer thread about having a "new" boost which
cleans up on its old outdated libraries and I am now thinking that this
here would be a rather good argument of doing such a change. In a first
step one might say that everything in boost should work well with the
std types (as long as there are no very good reasons not to do so),
while the boost duplicates would become deprecated. In a subsequent
change a boost/compat would be introduced with the sole purpose of
adding support for libraries that are used in boost but are broken on
compilers supported by boost (e.g. std::ref where it is broken). When
all broken compilers are faded out, the compat part is removed so that
at some point nothing is left.

While this would introduce a lot of work, it would, in the long run free
boost from the dilemma above.


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