Re: On free functions versus member functions

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2024-12-20 08:19:49

pt., 20 gru 2024 o 08:46 Ivan Matek <libbooze_at_[hidden]> napisał(a):

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

Sorry, I meant to say something like, "in an alternative language, we could
have ..". I agree: in C++ they are not orthogonal.

This is why I liked the idea of the pipeline operator.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2011r1.html

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

Agreed. I only put it so that you can weigh my opinion accordingly.

Regards,
&rzej;

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