Re: The new Boost 17.0.0

From: Edward Diener (eldiener_at_[hidden])
Date: 2020-12-01 21:29:35

On 12/1/2020 4:03 PM, Robert Ramey via Boost wrote:
> On 12/1/20 12:23 PM, Antony Polukhin via Boost wrote:
>> On Mon, Nov 30, 2020, 04:19 Raffi Enficiaud via Boost 
>> <boost_at_[hidden]>
> 
>> when the Boost library becomes part of the
>> iterface. For example, Boost.DLL needs shared_ptr and filesystem in it's
>> interface. Users suffer from boost::filesystem and boost::shared_ptr if
>> their projects use C++17 std:: alternatives.
> 
> I'm kind of intrigued with the idea of including things like shared_ptr 
> (and others) in a (user) library API.  I never do this.  In general, I 
> never use mutable references to mutable objects in any API.  That is I 
> always pass f(const T &).  So I never have to pass ownership to a user 
> function.  So I can pass a reference to some constant underlying type. 

You may still have to choose the type between Boost and a C++ standard 
alternative and no matter which type you choose the end-user may be 
using the other type in his code and be irritated that you are not using 
the type he is using.

> For example rather than
> 
> unsigned int string_hash( const std::string s &) {...}
> 
> I would use
> 
> unsigned int string_hash( const std::string s &) const {
>  Â Â Â Â return string_hash( s.c_str() );
> }
> 
> Of course making this change after the fact would be quite a bit of 
> work.  But since I do it from the beginning, it's no extra work at all. 
>  Â And it eliminates many, many problems including the one described 
> above. It's gotten to the point that for me, non constant parameters 
> parameters are code smell.  I almost never use them. And when I do, 
> usage is almost always confined to member functions.
> 
> I'm aware that this is actually off topic so sorry for hijaking the 
> thread.  But I believe that a lot of this (and other discussions), 
> rather than trying to address problems with reconciling boost and std 
> libraries would (mostly disappear) if users would step back and think 
> more about what functional program can mean in the real world.