Re: On free functions versus member functions

From: Ivan Matek (libbooze_at_[hidden])
Date: 2024-12-20 07:46:41

On Thu, Dec 19, 2024 at 11:20 PM Andrzej Krzemienski via Boost <
boost_at_[hidden]> wrote:

> czw., 19 gru 2024 o 18:04 Vinnie Falco via Boost <boost_at_[hidden]>
> napisał(a):
>
> In C++ we have what we have, but technically we could think about
> "encapsulation" and "member function notation" as two orthogonal things.
>

Can you elaborate? For me without UFCS this is *not* orthogonal. For
example my reading of P3021R0
<https://open-std.org/JTC1/SC22/WG21/docs/papers/2023/p3021r0.pdf> is that
std::begin is poor man's UFCS. Maybe I misunderstood you.

>
> I am personally not sold by the "discoverability" argument, because I
> mostly code in vim where I do not get any hints from the IDE anyway.
>

I personally do not use exceptions(except one I got from std::/libraries),
that does not mean I would oppose improvements for people who use
exceptions.
Not every improvement needs to benefit 70+% of users.

On Fri, Dec 20, 2024 at 12:57 AM Vinnie Falco via Boost <
boost_at_[hidden]> wrote:

>     std::unordered_map< int, char > m;
>
>     upgrade(m).try_find( 1 ).map(
>         []( auto&& v )
>         {
>             std::cout << "not empty";
>             return v;
>         }
>     );
>

I do not think people will be happy to use this pattern because it beside
it being verbose it requires wrap on every use, would be better if it was a
type wrapper that inherits public interface of container
e.g.
in class you have member
boost::fancy<flat_unordered_map<int, User>>  user_id_to_user_; // has find,
size, ... + try_at

so every use of user_id_to_user_ does not need upgrade wrap call.

Issue here is that  you can not inherit from containers(or you can, but you
shouldn't). This is a well known issue in C++.

To go back to adding member function and concern about code duplication.
To reduce code duplication you could add CRTP helper base class that
provides try_at for every container that implements find and inherits from
it.
In my opinion using CRTP to avoid 5 lines of duplicated code is not worth
it. But I could be wrong.
As existing example unordered_flat_set, unordered_flat_map,
unordered_node_map, unordered_node_set all have same implementation of count
/contains, there may be some value in extracting "nice/utility" members
that can be implemented using "core" functionality(in this case find + end
).

i.e. maybe this same code in those classes:

BOOST_FORCEINLINE bool contains(key_type const& key) const
{
  return this->find(key) != this->end();
}

BOOST_FORCEINLINE size_type count(key_type const& key) const
{
  auto pos = table_.find(key);
  return pos != table_.end() ? 1 : 0;
}

could be moved to some base helper? In that case try_at can also live there.

P.S.
regarding godbolt code: I know it is not production code, but I think you
do not need std::forward in try_find.