Boost logo

Boost :

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2024-12-21 13:15:04


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

Could you explain what the issue is? I do not believe I have ever heard of
it.

Regards,
&rzej;


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk