Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c++
Subject: Re: C++ named requirements as concepts
Date: Fri, 11 Oct 2024 04:58:29 -0700
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <8634l2zw9m.fsf@linuxsc.com>
References: <vcn7kn$1n3bh$2@dont-email.me> <vdehu2$29uog$1@dont-email.me> <vdeoej$2b22u$1@dont-email.me> <vdg8qn$2l73s$1@dont-email.me> <vdga7d$2lbv9$1@raubtier-asyl.eternal-september.org> <vdgcku$2lih8$1@dont-email.me> <20241001125332.000058ba@yahoo.com> <vdghc8$2me2g$1@dont-email.me> <20241001131141.000016b1@yahoo.com> <vdh739$2q4kk$1@dont-email.me> <20241001215050.000027aa@yahoo.com> <86bk0319w3.fsf@linuxsc.com> <20241002130236.000005e0@yahoo.com> <8634lc0y43.fsf@linuxsc.com> <20241006141907.00005a57@yahoo.com> <86iku3zydq.fsf@linuxsc.com> <20241007225315.00006d81@yahoo.com> <ve3i3c$27d8p$1@dont-email.me> <20241008224816.00004f1d@yahoo.com> <ve477p$2ajn8$1@dont-email.me> <20241009010605.00001699@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Fri, 11 Oct 2024 13:58:33 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7c69fe22f3f04b1159714f26b61f0388"; logging-data="3846863"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/BvcOTA4G+ku8C+CKaQio6XxBNrblCTFw="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:6AyzGfSA3VOfxYLH+9FwA0GSauY= sha1:6ryYs2kCSRmn9VwP63LVbscGhJc=
Xref: csiph.com comp.lang.c++:120700

Michael S <already5chosen@yahoo.com> writes:

> On Wed, 9 Oct 2024 00:12:25 +0300
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>
>> The context state is the bread and butter of lambda.  If all you
>> want is to avoid operator(), this can be done easily:
>
> I want neither operator() nor lambda.
> I want a way to feed std::sort with honest old [pointer to] object
> + [pointer to] its honest old member function.  And I am not
> obsessed with idea that it has to be a single prameter at all
> cost;  I see nothing wrong if two separate parameters needed to do
> the job.

I think I understand your position.  Without meaning to challenge
that, I would like to offer my perspective on the situation.

There are several ways a "stateful function" argument might be
provided;  some examples:

   pointer to function, along with either a separate context
   pointer or a bundled context/function pointer (illustrated
   in a recent post in comp.lang.c)

   having a parameter type of pointer to abstract superclass,
   with a virtual function to accommodate caller-specific
   functionality (not sure if a separate pointer-to-member
   argument makes sense here)

   a pointer-to templated class parameter, using either a
   fixed member function name or a separate pointer-to-member
   argument

   a lambda (which could be either a stateful lambda or a
   pure lambda along with a separate context argument)

To me all of these choices are conceptually pretty much the same,
having only minor differences in the details.  A plausible
analogy is comparing for() and while(), or if-then-else and
switch().

Because I don't see much difference between them, what I want is
whatever makes it most convenient for the caller.  Usually "most
convenient" means the choice that uses the least code in the
caller, although that might be affected by how clunky the code
is for the different cases.

Of course which choice is most convenient depends on what is
going on in the caller.  In some cases a lambda is easiest;
in other cases a templated class parameter with a separate
pointer-to-member could be better.  Which choice or choices
should be accommodated depends on what the expected use cases
are.  The guiding principle remains What offers the easiest
and best fit in the caller (or callers plural)?

So for what it's worth there is my approach to the question.