Re: [boost] On free functions versus member functions

pt., 20 gru 2024 o 08:46 Ivan Matek napisał(a):

On Thu, Dec 19, 2024 at 11:20 PM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:

...

czw., 19 gru 2024 o 18:04 Vinnie Falco via Boost 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@lists.boost.org> 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> 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.