Re: [boost] Curiousity question

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.

Best,
Oswin