Re: The new Boost 17.0.0

From: Robert Ramey (ramey_at_[hidden])
Date: 2020-12-01 21:03:55

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. 
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.

Robert Ramey