On Wed, Jun 12, 2024 at 12:59 PM Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Wed, 12 Jun 2024 at 01:23, Jason McKesson via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Tue, Jun 11, 2024 at 6:15 PM Aeren via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>>
>> > 2. The example I gave applies to any setting that can be abstracted
>> into that form, and it looked general enough that whenever you're dealing
>> with optimization over multivariate functions, I thought that this proposal
>> can be very useful. I'm not sure how adding "competitive programming"
>> changes anything. Would it be better if I instead wrote "I found this
>> abstractization in my production code"?
>>
>> Did you?
>>
>> Changes to the standard should be motivated by a desire to help
>> working programmers do their jobs better. They shouldn't be motivated
>> by people playing around with the language. People can do that, but
>> the language shouldn't change just to help them. As such, citing
>> "competitive programming" examples is not a *convincing* way to get
>> other people to think that this is a problem that needs solving.
>>
>
> Because from what I've seen, competitive programming problems often seem
> to be written to be challenging *for the sake of it*. To make you think.
>
> Presumably, if std::set::partition_point got added and became the obvious
> go-to solution for this type of competition problem, that type of problem
> becomes too easy and won't be set. Because the solution is "just call a
> standard library function", which is not challenging. So now the only use
> case you presented, competitive programming, is no longer a use case. And
> we would have something in the standard that nobody is going to use.
>

> Of course if it's useful in real code outside of "hard for the sake of
> making you solve the problem" then it _would_ get used, and so might be
> worth adding to the standard. Which is why we're going to give more weight
> to real world use cases, not speed running algorithmic puzzles.
>

The real challenge, in this particular type of problem, is to devise some
complex algorithm where a self-balancing binary search tree is simply one
of the data structures required in order to make the algorithm efficient.
Realizing that you can solve the problem with a binary search tree is the
hard part. Then, you run into the awkward problem where standard library
implementations already contain self-balancing binary search trees, they
just don't expose them to you directly.

I'd like to solve the problem once and for all by standardizing something
akin to Boost.Intrusive, but that's a massive effort that may be more
trouble than it's worth.


>
> Also, as a std::lib maintainer, I am at the sharp end of "I want to win
> competitions but I want somebody else to implement the actual code and ship
> it in a standard library". So I want *extra* persuasion that this is
> actually useful.
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*