Re: [boost] Curiousity question

On 2016-10-13 17:09, Vinnie Falco wrote:

On Thu, Oct 13, 2016 at 10:54 AM, Edward Diener 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