On 12/1/20 12:23 PM, Antony Polukhin via Boost wrote:
On Mon, Nov 30, 2020, 04:19 Raffi Enficiaud via Boost
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