Re: [boost] On free functions versus member functions

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.

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