Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #120608 > unrolled thread

Lambda in STL compare

Back to article view | Back to comp.lang.c++

Contents

  Lambda in STL compare Muttley@DastartdlyHQ.org - 2024-10-07 07:32 +0000
    Re: Lambda in STL compare Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-07 10:12 +0200
      Re: Lambda in STL compare Muttley@DastartdlyHQ.org - 2024-10-07 09:32 +0000
    Re: Lambda in STL compare David Brown <david.brown@hesbynett.no> - 2024-10-07 10:16 +0200
    Re: Lambda in STL compare Sam <sam@email-scan.com> - 2024-10-07 07:35 -0400
      Re: Lambda in STL compare Muttley@DastartdlyHQ.org - 2024-10-07 14:06 +0000
        Re: Lambda in STL compare Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-07 16:13 +0200
          Re: Lambda in STL compare Muttley@DastartdlyHQ.org - 2024-10-07 14:53 +0000
            Re: Lambda in STL compare Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-07 17:06 +0200
              Re: Lambda in STL compare Muttley@DastartdlyHQ.org - 2024-10-07 15:46 +0000
                Re: Lambda in STL compare Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-07 17:55 +0200
                  Re: Lambda in STL compare Muttley@DastartdlyHQ.org - 2024-10-08 08:23 +0000
                    Re: Lambda in STL compare Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-08 10:25 +0200
                      Re: Lambda in STL compare Muttley@DastartdlyHQ.org - 2024-10-08 10:24 +0000
                        Re: Lambda in STL compare Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-08 13:10 +0200
        Re: Lambda in STL compare Sam <sam@email-scan.com> - 2024-10-08 08:25 -0400
          Re: Lambda in STL compare Muttley@DastartdlyHQ.org - 2024-10-08 14:44 +0000
            Re: Lambda in STL compare Sam <sam@email-scan.com> - 2024-10-08 17:52 -0400
              Re: Lambda in STL compare "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-08 22:56 -0700
              Re: Lambda in STL compare Muttley@DastartdlyHQ.org - 2024-10-09 07:15 +0000
                Re: Lambda in STL compare Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-09 09:21 +0200
                  Re: Lambda in STL compare Muttley@DastartdlyHQ.org - 2024-10-09 07:22 +0000
              Re: Lambda in STL compare Muttley@DastartdlyHQ.org - 2024-10-09 07:16 +0000
                Re: Lambda in STL compare "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-10-09 00:23 -0700
    Re: Lambda in STL compare Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-10-07 07:17 -0700

Page 1 of 2  [1] 2  Next page →

#120608 — Lambda in STL compare

Isn't it about time that lambda functions could be used directly as STL
comparitors instead of it being an ugly 2 step process? 

ie instead of:

auto comp = [](const string &s1, const string &s2)
{
	return strcasecmp(s1.c_str(),s2.c_str()) < 0;
};
map<string,int,decltype(comp)> m(comp);

which is no simpler than just using a functor, why can't we just do:

map<string,int,[](const string &s1, const string &s2)
{
        return strcasecmp(s1.c_str(),s2.c_str()) < 0;
}) m;

I'm sure updating the compilers so a lambda could be a template parameter 
wouldn't be beyond the wit of man.

Rather than adding esoteric functionality no one uses wouldn't it be better
to tidy up what there is already?

[toc] | [next] | [standalone]

#120609

Am 07.10.2024 um 09:32 schrieb Muttley@DastartdlyHQ.org:
> Isn't it about time that lambda functions could be used directly as STL
> comparitors instead of it being an ugly 2 step process?
> 
> ie instead of:
> 
> auto comp = [](const string &s1, const string &s2)
> {
> 	return strcasecmp(s1.c_str(),s2.c_str()) < 0;
> };
> map<string,int,decltype(comp)> m(comp);
> 
> which is no simpler than just using a functor, why can't we just do:
> 
> map<string,int,[](const string &s1, const string &s2)
> {
>          return strcasecmp(s1.c_str(),s2.c_str()) < 0;
> }) m;
> 
> I'm sure updating the compilers so a lambda could be a template parameter
> wouldn't be beyond the wit of man.
> 
> Rather than adding esoteric functionality no one uses wouldn't it be better
> to tidy up what there is already?
> 

Lambdas can be used in an unevaluated context since C++20, i.e
you could write <, decltype([]( ... ) { })> as you did. Try it
with -std=c++20 / -std:c++29.

[toc] | [prev] | [next] | [standalone]

#120612

On Mon, 7 Oct 2024 10:12:03 +0200
Bonita Montero <Bonita.Montero@gmail.com> boring babbled:
>Am 07.10.2024 um 09:32 schrieb Muttley@DastartdlyHQ.org:
>> Isn't it about time that lambda functions could be used directly as STL
>> comparitors instead of it being an ugly 2 step process?
>> 
>> ie instead of:
>> 
>> auto comp = [](const string &s1, const string &s2)
>> {
>> 	return strcasecmp(s1.c_str(),s2.c_str()) < 0;
>> };
>> map<string,int,decltype(comp)> m(comp);
>> 
>> which is no simpler than just using a functor, why can't we just do:
>> 
>> map<string,int,[](const string &s1, const string &s2)
>> {
>>          return strcasecmp(s1.c_str(),s2.c_str()) < 0;
>> }) m;
>> 
>> I'm sure updating the compilers so a lambda could be a template parameter
>> wouldn't be beyond the wit of man.
>> 
>> Rather than adding esoteric functionality no one uses wouldn't it be better
>> to tidy up what there is already?
>> 
>
>Lambdas can be used in an unevaluated context since C++20, i.e
>you could write <, decltype([]( ... ) { })> as you did. Try it
>with -std=c++20 / -std:c++29.

I did, didn't work. But then the version of clang in MacOS is always behind
the times. It supports the -std=c++20 option but doesn't seem to honour all
of the 2020 spec yet.

Anyway, good to know thats been sorted.

[toc] | [prev] | [next] | [standalone]

#120610

On 07/10/2024 09:32, Muttley@DastartdlyHQ.org wrote:
> Isn't it about time that lambda functions could be used directly as STL
> comparitors instead of it being an ugly 2 step process?
> 
> ie instead of:
> 
> auto comp = [](const string &s1, const string &s2)
> {
> 	return strcasecmp(s1.c_str(),s2.c_str()) < 0;
> };
> map<string,int,decltype(comp)> m(comp);
> 
> which is no simpler than just using a functor, why can't we just do:
> 
> map<string,int,[](const string &s1, const string &s2)
> {
>          return strcasecmp(s1.c_str(),s2.c_str()) < 0;
> }) m;
> 
> I'm sure updating the compilers so a lambda could be a template parameter
> wouldn't be beyond the wit of man.
> 
> Rather than adding esoteric functionality no one uses wouldn't it be better
> to tidy up what there is already?
> 

After fixing the typos (you missed part of the "decltype"), it compiles 
fine:

map<string, int, decltype([](const string &s1, const string &s2)
{
          return strcasecmp(s1.c_str(), s2.c_str()) < 0;
})> m;


(Warning - I've only compiled this on godbolt, not tested it to see if 
it works!)


The key point is that in C++20, lambda closures got a default 
constructor if they have no captures.

It would, however, be even nicer if there were no need for "decltype" here.

[toc] | [prev] | [next] | [standalone]

#120613

Muttley@DastartdlyHQ.org writes:

> which is no simpler than just using a functor, why can't we just do:
>
> map<string,int,[](const string &s1, const string &s2)
> {
>         return strcasecmp(s1.c_str(),s2.c_str()) < 0;
> }) m;
>
> I'm sure updating the compilers so a lambda could be a template parameter
> wouldn't be beyond the wit of man.

The reason we cannot do that is because the third parameter to std::map is a  
type, and not an object. A lambda expression is an instance of an anonymous  
type, and not a type in of itself.

[toc] | [prev] | [next] | [standalone]

#120614

On Mon, 07 Oct 2024 07:35:34 -0400
Sam <sam@email-scan.com> boring babbled:
>Muttley@DastartdlyHQ.org writes:
>
>> which is no simpler than just using a functor, why can't we just do:
>>
>> map<string,int,[](const string &s1, const string &s2)
>> {
>>         return strcasecmp(s1.c_str(),s2.c_str()) < 0;
>> }) m;
>>
>> I'm sure updating the compilers so a lambda could be a template parameter
>> wouldn't be beyond the wit of man.
>
>The reason we cannot do that is because the third parameter to std::map is a  
>type, and not an object. A lambda expression is an instance of an anonymous  
>type, and not a type in of itself.

Its a definition, not a value, so why can't it silently be converted internally
by the compiler? Presumably it does just that when it sees decltype anyway.

[toc] | [prev] | [next] | [standalone]

#120615

Am 07.10.2024 um 16:06 schrieb Muttley@DastartdlyHQ.org:

> Its a definition, not a value, ...

Wrong, a lambda is a PR-value.

[toc] | [prev] | [next] | [standalone]

#120617

On Mon, 7 Oct 2024 16:13:48 +0200
Bonita Montero <Bonita.Montero@gmail.com> boring babbled:
>Am 07.10.2024 um 16:06 schrieb Muttley@DastartdlyHQ.org:
>
>> Its a definition, not a value, ...
>
>Wrong, a lambda is a PR-value.

I don't see why it can't be cast to std::function. It is a function after all.

[toc] | [prev] | [next] | [standalone]

#120618

Am 07.10.2024 um 16:53 schrieb Muttley@DastartdlyHQ.org:
> On Mon, 7 Oct 2024 16:13:48 +0200
> Bonita Montero <Bonita.Montero@gmail.com> boring babbled:
>> Am 07.10.2024 um 16:06 schrieb Muttley@DastartdlyHQ.org:
>>
>>> Its a definition, not a value, ...
>>
>> Wrong, a lambda is a PR-value.
> 
> I don't see why it can't be cast to std::function. It is a function after all.

Of course you can cast it to a compatible function, i.e. the parmeters
of the lambda and the parameter supplied to the function must match.

[toc] | [prev] | [next] | [standalone]

#120620

On Mon, 7 Oct 2024 17:06:11 +0200
Bonita Montero <Bonita.Montero@gmail.com> boring babbled:
>Am 07.10.2024 um 16:53 schrieb Muttley@DastartdlyHQ.org:
>> On Mon, 7 Oct 2024 16:13:48 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> boring babbled:
>>> Am 07.10.2024 um 16:06 schrieb Muttley@DastartdlyHQ.org:
>>>
>>>> Its a definition, not a value, ...
>>>
>>> Wrong, a lambda is a PR-value.
>> 
>> I don't see why it can't be cast to std::function. It is a function after
>all.
>
>Of course you can cast it to a compatible function, i.e. the parmeters
>of the lambda and the parameter supplied to the function must match.

The compiler knows exactly what the parameters are. Try thinking outside
of the box. The semantic rules are not immutable laws of physics.

[toc] | [prev] | [next] | [standalone]

#120621

Am 07.10.2024 um 17:46 schrieb Muttley@DastartdlyHQ.org:

> The compiler knows exactly what the parameters are. ..

The parameters of a function-object must be convertible to
those of the lambda. That's all.

[toc] | [prev] | [next] | [standalone]

#120634

On Mon, 7 Oct 2024 17:55:14 +0200
Bonita Montero <Bonita.Montero@gmail.com> boring babbled:
>Am 07.10.2024 um 17:46 schrieb Muttley@DastartdlyHQ.org:
>
>> The compiler knows exactly what the parameters are. ..
>
>The parameters of a function-object must be convertible to
>those of the lambda. That's all.

So make it convertable. I find it perverse that the declaration of a struct/
class and the declaration of a function/lambda are considered different types
of declarations. The compiler should see that its being used in a template and
act accordingly.

[toc] | [prev] | [next] | [standalone]

#120635

Am 08.10.2024 um 10:23 schrieb Muttley@DastartdlyHQ.org:

> So make it convertable. I find it perverse that the declaration of a struct/
> class and the declaration of a function/lambda are considered different types
> of declarations. ..


In one case you have a variable-_defintiion_, in the other a declaration.

[toc] | [prev] | [next] | [standalone]

#120636

On Tue, 8 Oct 2024 10:25:33 +0200
Bonita Montero <Bonita.Montero@gmail.com> boring babbled:
>Am 08.10.2024 um 10:23 schrieb Muttley@DastartdlyHQ.org:
>
>> So make it convertable. I find it perverse that the declaration of a struct/
>> class and the declaration of a function/lambda are considered different types
>
>> of declarations. ..
>
>
>In one case you have a variable-_defintiion_, in the other a declaration.

No, they're both declarations. The only difference is how you assign them
to variables.

[](whatever) { } 

is not a variable, its a definition.

auto lambda = [](whatever) { }

is a variable declaration and assignment.

[toc] | [prev] | [next] | [standalone]

#120637

Am 08.10.2024 um 12:24 schrieb Muttley@DastartdlyHQ.org:
> On Tue, 8 Oct 2024 10:25:33 +0200
> Bonita Montero <Bonita.Montero@gmail.com> boring babbled:
>> Am 08.10.2024 um 10:23 schrieb Muttley@DastartdlyHQ.org:
>>
>>> So make it convertable. I find it perverse that the declaration of a struct/
>>> class and the declaration of a function/lambda are considered different types
>>
>>> of declarations. ..
>>
>>
>> In one case you have a variable-_defintiion_, in the other a declaration.
> 
> No, they're both declarations. ..

No, the implcit definition isn't usually seen, but just with a decltype().

[toc] | [prev] | [next] | [standalone]

#120638

Muttley@DastartdlyHQ.org writes:

> On Mon, 07 Oct 2024 07:35:34 -0400
> Sam <sam@email-scan.com> boring babbled:
> >The reason we cannot do that is because the third parameter to std::map is a
> >type, and not an object. A lambda expression is an instance of an anonymous
> >type, and not a type in of itself.
>
> Its a definition, not a value, so why can't it silently be converted  
> internally
> by the compiler? Presumably it does just that when it sees decltype anyway.

Because it's not the compiler's job to invent new templates. If there was an  
overloaded template whose third parameter is an object, then, I suppose,  
things will work this way. But there isn't one.

[toc] | [prev] | [next] | [standalone]

#120641

On Tue, 08 Oct 2024 08:25:33 -0400
Sam <sam@email-scan.com> boring babbled:
>Muttley@DastartdlyHQ.org writes:
>
>> On Mon, 07 Oct 2024 07:35:34 -0400
>> Sam <sam@email-scan.com> boring babbled:
>> >The reason we cannot do that is because the third parameter to std::map is a
>
>> >type, and not an object. A lambda expression is an instance of an anonymous
>> >type, and not a type in of itself.
>>
>> Its a definition, not a value, so why can't it silently be converted  
>> internally
>> by the compiler? Presumably it does just that when it sees decltype anyway.
>
>Because it's not the compiler's job to invent new templates. If there was an  

Its the compilers job to interpret the template. Given the semantic hoops,
gotchas,hacks and generalinconsistencies C++ already has, another one that 
might actually be useful isn't going to hurt.

[toc] | [prev] | [next] | [standalone]

#120650

Muttley@DastartdlyHQ.org writes:

> On Tue, 08 Oct 2024 08:25:33 -0400
> Sam <sam@email-scan.com> boring babbled:
> >
> >Because it's not the compiler's job to invent new templates. If there was an
>
> Its the compilers job to interpret the template. Given the semantic hoops,
> gotchas,hacks and generalinconsistencies C++ already has, another one that
> might actually be useful isn't going to hurt.

Hm, I'm beginning to think you're right. After all, C++ has always had a  
reputation of being too simplistic, straightforward, and easy to learn and  
understand. It's about time some complexity was added to the language.

[toc] | [prev] | [next] | [standalone]

#120654

On 10/8/2024 2:52 PM, Sam wrote:
> Muttley@DastartdlyHQ.org writes:
> 
>> On Tue, 08 Oct 2024 08:25:33 -0400
>> Sam <sam@email-scan.com> boring babbled:
>> >
>> >Because it's not the compiler's job to invent new templates. If there 
>> was an
>>
>> Its the compilers job to interpret the template. Given the semantic 
>> hoops,
>> gotchas,hacks and generalinconsistencies C++ already has, another one 
>> that
>> might actually be useful isn't going to hurt.
> 
> Hm, I'm beginning to think you're right. After all, C++ has always had a 
> reputation of being too simplistic, straightforward, and easy to learn 
> and understand. It's about time some complexity was added to the language.

Yikes! ;^)

[toc] | [prev] | [next] | [standalone]

#120656

On Tue, 08 Oct 2024 17:52:25 -0400
Sam <sam@email-scan.com> boring babbled:
>Muttley@DastartdlyHQ.org writes:
>
>> On Tue, 08 Oct 2024 08:25:33 -0400
>> Sam <sam@email-scan.com> boring babbled:
>> >
>> >Because it's not the compiler's job to invent new templates. If there was an
>
>>
>> Its the compilers job to interpret the template. Given the semantic hoops,
>> gotchas,hacks and generalinconsistencies C++ already has, another one that
>> might actually be useful isn't going to hurt.
>
>Hm, I'm beginning to think you're right. After all, C++ has always had a  
>reputation of being too simplistic, straightforward, and easy to learn and  
>understand. It's about time some complexity was added to the language.

I happen to think the removal of the need for decltype() would actually
simplify things. Are there any instances where a piece of code would compile
with and without decltype but otherwise is identical? If not then what harm
would it do to make the compiler infer its a type instead of having to
be explicily told? After all, thats the rationale behind "auto".

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web