On Saturday, 18 December 2021 at 16:31:23 UTC+2, Bonita Montero wrote:
> > Lambdas are just syntax simplification of few things ...
>
> No, it's not "just" syntax-simplification, it's the ease of use
> to prevent a lot of redundant code and to write objects with only
> a calling operator in one line.

That is definition of the syntax sugar. No effects to result just different
way to type it in. There already was Boost.Bind template for generating
such classes and objects of such classes on same line ... for whatever
reason it was also added to C++11 as std::bind.

> > From syntax sugar improvements the range-based-for and variadic
> > templates are also far better than lambdas ...
>
> They're not comparable since they solve completely different
> purposes.

But you compared them first by saying that lambdas are most
important. Why you compared non-comparable thing?

> > because these make code more elegant without adding any weird
> > garbage or confusion.
> Lambdas are not confusing. But variadic templates can be very confusing.

Nonsense. Lambdas are often just copy paste bloat with garbled syntax
while variadic templates made lot of template code far shorter.
So snip and run with nonsense? Restoring:

# C++11 added several performance improvements like move semantics,
# constexpr, noexcept, split concepts of trivial classes and standard layout
# classes, even underlying type of enum. These are all better than syntax
# sugar because these help to have more efficient product.
# # Therefore only the optional cosmetic things like nullptr, final, override,
# enum class, explicit, etc. are less important than lambdas.

Am 18.12.2021 um 16:12 schrieb Öö Tiib:

> That is definition of the syntax sugar. No effects to result just different.

Syntactic sugar is when there's no major improvement also. But here
the improvement is huge because you have to write much less code and
the code becomes much more readable-.

> There already was Boost.Bind template for generating
> such classes and objects of such classes on same line ...

The ease of C++ lambdas isn't substitutable.

> But you compared them first by saying that lambdas are most
> important. Why you compared non-comparable thing?

My comparison was from the standpoint of code-length and readability.

> Nonsense. Lambdas are often just copy paste bloat ...

Lambdas usually save a lot of redundant code and make the code much
more readable.

> ... with garbled syntax ...

The syntax is trivial.

> ... while variadic templates made lot of template code far shorter. ..

Variadic templates make templates not easier but make tmplated
things possible which weren't possible before. But they can be
tricky to use.

On 17/12/2021 18:30, Öö Tiib wrote:
> On Thursday, 16 December 2021 at 21:14:46 UTC+2, David Brown wrote:
>>
>> The simplest lambda is therefore: [](){}, and can be defined then
>> immediately called as [](){}(). C++ is a happy language with lots of
>> smilies!
>
> Yes. I've been surprised when some people say that it is oh so
> readable.
> Handy? Very. Happy? Perhaps. Readable? Hmm.
>

Obviously real uses of lambdas look different. Like pretty much any
feature of any programming language, they can be used well to improve
code and make it clearer, more maintainable, more readable, more
efficient - or they can be used poorly with worse results. (And "more
readable" is always subjective and context-dependent.)

On 17/12/2021 19:19, Bart wrote:
> On 16/12/2021 19:14, David Brown wrote:
>> On 16/12/2021 19:00, Bart wrote:
>
>>> So the lambda here is the local 'function' that includes that '[&]`
>>> (according to BB)?
>>
>> The syntax for a lambda in C++ is basically a "[]" bit that can include
>> captures (by value or reference) that replaces the function name in a
>> normal function definition.  And the return type is either deduced
>> automatically, or given with the newer "-> T" syntax rather than ahead
>> of the function name.
>>
>> The simplest lambda is therefore: [](){}, and can be defined then
>> immediately called as [](){}().  C++ is a happy language with lots of
>> smilies!
>
> I tried to add <> in there but it didn't work.
>

With C++20, you can add <> brackets to make a templated lambda.
Unfortunately, you need something inside the brackets. But if you want,
you can write:

[]<int...>(){}();

(In reality, lambdas can be useful in C++ just like in many other
languages. Don't let this silliness put you off them.)

Öö Tiib <ootiib@hot.ee> writes:

> Lambdas are just syntax simplification of few things

and later...

> C++11 added several performance improvements like move semantics,
> constexpr, noexcept, split concepts of trivial classes and standard layout
> classes, even underlying type of enum. These are all better than syntax
> sugar because these help to have more efficient product.

Both of which are striking things to say, but there has already been too
much discussion of C++ in comp.lang.c for me to feel happy to add more.
(I think it's deliberate on BM's part.)

--
Ben.

On Sunday, 19 December 2021 at 01:38:17 UTC+2, Ben Bacarisse wrote:
> Öö Tiib <oot...@hot.ee> writes:
>
> > Lambdas are just syntax simplification of few things
>
> and later...
>
> > C++11 added several performance improvements like move semantics,
> > constexpr, noexcept, split concepts of trivial classes and standard layout
> > classes, even underlying type of enum. These are all better than syntax
> > sugar because these help to have more efficient product.
>
> Both of which are striking things to say, but there has already been too
> much discussion of C++ in comp.lang.c for me to feel happy to add more.
> (I think it's deliberate on BM's part.)

I also realized that so I stopped answering to BM yesterday. Otherwise the
constexpr and underlying types to enums I would love to have in C too.
The constexpr lets to use most of language compile time. That is likely
tricky to implement from scratch but as gcc and clang both have it
anyway then why not. It is rather good both for performance
and testing. The underlying types to enums let to have one byte wide
enums. That is good for performance and also portability in communications.
I do not think it is rather tricky feature.

On 19/12/2021 18:40, Öö Tiib wrote:
> On Sunday, 19 December 2021 at 01:38:17 UTC+2, Ben Bacarisse wrote:
>> Öö Tiib <oot...@hot.ee> writes:
>>
>>> Lambdas are just syntax simplification of few things
>>
>> and later...
>>
>>> C++11 added several performance improvements like move semantics,
>>> constexpr, noexcept, split concepts of trivial classes and standard layout
>>> classes, even underlying type of enum. These are all better than syntax
>>> sugar because these help to have more efficient product.
>>
>> Both of which are striking things to say, but there has already been too
>> much discussion of C++ in comp.lang.c for me to feel happy to add more.
>> (I think it's deliberate on BM's part.)
>
> I also realized that so I stopped answering to BM yesterday. Otherwise the
> constexpr and underlying types to enums I would love to have in C too.
> The constexpr lets to use most of language compile time. That is likely
> tricky to implement from scratch but as gcc and clang both have it
> anyway then why not.

Yeah, in complicated compilers for a complicated language, so more
complication will hardly be noticed!

I have a problem with that feature: since this is user-code being run at
compile-time, how long is a compiler prepared to spend executing such
code? How worthwhile is that effort if it turns out that only a fraction
of it, or none, is actually during any specific run?

The following is something I've just tried; it took nearly 5 seconds to
compile:

#include <stdio.h>

constexpr long long int fib(long long int n) {
long long int a;
if (n<3)
a=1;
else
a=fib(n-2)+fib(n-1);
return a;
}

int A[fib(42)/1000000];

int main(void) {
printf("%d\n", fib(42));
printf("%d\n", sizeof(A)/sizeof(A[0]));
}

Without the constexpr, and using a literal for A's size, it took 0.23
seconds.

It's scary might might happen in a substantional application.

Am 19.12.2021 um 20:07 schrieb Bart:

> Yeah, in complicated compilers for a complicated language, so more
> complication will hardly be noticed!

The benefit is: you write much less complicated code than with C.

On Sunday, 19 December 2021 at 21:07:45 UTC+2, Bart wrote:
> On 19/12/2021 18:40, Öö Tiib wrote:
> > On Sunday, 19 December 2021 at 01:38:17 UTC+2, Ben Bacarisse wrote:
> >> Öö Tiib <oot...@hot.ee> writes:
> >>
> >>> Lambdas are just syntax simplification of few things
> >>
> >> and later...
> >>
> >>> C++11 added several performance improvements like move semantics,
> >>> constexpr, noexcept, split concepts of trivial classes and standard layout
> >>> classes, even underlying type of enum. These are all better than syntax
> >>> sugar because these help to have more efficient product.
> >>
> >> Both of which are striking things to say, but there has already been too
> >> much discussion of C++ in comp.lang.c for me to feel happy to add more..
> >> (I think it's deliberate on BM's part.)
> >
> > I also realized that so I stopped answering to BM yesterday. Otherwise the
> > constexpr and underlying types to enums I would love to have in C too.
> > The constexpr lets to use most of language compile time. That is likely
> > tricky to implement from scratch but as gcc and clang both have it
> > anyway then why not.
> Yeah, in complicated compilers for a complicated language, so more
> complication will hardly be noticed!
>
> I have a problem with that feature: since this is user-code being run at
> compile-time, how long is a compiler prepared to spend executing such
> code? How worthwhile is that effort if it turns out that only a fraction
> of it, or none, is actually during any specific run?

It like every other feature depends on how programmer uses it. It can
compile 5 seconds longer but start program quicker or it can build
executable quicker but hang 5 seconds at start of every run. Or both,
or neither.

If you are paranoid that your team members sabotage your project
with pointless compile time processing then reduce the maximum
steps of constexpr evaluation in your continuous integration server.

However one who's clever enough can do it with preprocessor
metaprogramming and recursive #includes in C as easily as in
your C++ example. So better hire a team that you trust.

On 12/10/2021 10:36 PM, Mehdi Amini wrote:
> Hi,
>
> Which book or tutorial would you recommend for standard C threads
> introduced in C11 ?

Actually, C11 threads is pretty damn close to POSIX threads. Therefore:

https://books.google.com/books/about/Programming_with_POSIX_Threads.html?id=_xvnuFzo7q0C

Is a nice starter. I had the pleasure to converse with him over on
comp.programming.threads. Very smart man, indeed!

:^)

Am 20.12.2021 um 02:23 schrieb Chris M. Thomasson:
> On 12/10/2021 10:36 PM, Mehdi Amini wrote:
>> Hi,
>>
>> Which book or tutorial would you recommend for standard C threads
>> introduced in C11 ?
>
> Actually, C11 threads is pretty damn close to POSIX threads. Therefore:
>
> https://books.google.com/books/about/Programming_with_POSIX_Threads.html?id=_xvnuFzo7q0C
>
>
> Is a nice starter. I had the pleasure to converse with him over on
> comp.programming.threads. Very smart man, indeed!
>
> :^)

Take this:

https://ptgmedia.pearsoncmg.com/images/9780201633924/samplepages/0201633922.pdf

On Sunday, 19 December 2021 at 20:41:46 UTC, Öö Tiib wrote:
> On Sunday, 19 December 2021 at 21:07:45 UTC+2, Bart wrote:
> > On 19/12/2021 18:40, Öö Tiib wrote:
> > > On Sunday, 19 December 2021 at 01:38:17 UTC+2, Ben Bacarisse wrote:
> > >> Öö Tiib <oot...@hot.ee> writes:
> > >>
> > >>> Lambdas are just syntax simplification of few things
> > >>
> > >> and later...
> > >>
> > >>> C++11 added several performance improvements like move semantics,
> > >>> constexpr, noexcept, split concepts of trivial classes and standard layout
> > >>> classes, even underlying type of enum. These are all better than syntax
> > >>> sugar because these help to have more efficient product.
> > >>
> > >> Both of which are striking things to say, but there has already been too
> > >> much discussion of C++ in comp.lang.c for me to feel happy to add more.
> > >> (I think it's deliberate on BM's part.)
> > >
> > > I also realized that so I stopped answering to BM yesterday. Otherwise the
> > > constexpr and underlying types to enums I would love to have in C too..
> > > The constexpr lets to use most of language compile time. That is likely
> > > tricky to implement from scratch but as gcc and clang both have it
> > > anyway then why not.
> > Yeah, in complicated compilers for a complicated language, so more
> > complication will hardly be noticed!
> >
> > I have a problem with that feature: since this is user-code being run at
> > compile-time, how long is a compiler prepared to spend executing such
> > code? How worthwhile is that effort if it turns out that only a fraction
> > of it, or none, is actually during any specific run?
> It like every other feature depends on how programmer uses it. It can
> compile 5 seconds longer but start program quicker or it can build
> executable quicker but hang 5 seconds at start of every run. Or both,
> or neither.
>
> If you are paranoid that your team members sabotage your project
> with pointless compile time processing then reduce the maximum
> steps of constexpr evaluation in your continuous integration server.
>
> However one who's clever enough can do it with preprocessor
> metaprogramming and recursive #includes in C as easily as in
> your C++ example. So better hire a team that you trust.
>
We had a case. Someone put in an innocent-seeming compile time
const expression in C++. It worked on the development machines.
Then when pushed to the CI server, it broke.

It's the type of thing which can be quite hard for another programmer to
fix quickly, because you've got to replace the functionality with a totally
different construct.

On Monday, 20 December 2021 at 13:21:46 UTC+2, Malcolm McLean wrote:
> On Sunday, 19 December 2021 at 20:41:46 UTC, Öö Tiib wrote:
> > On Sunday, 19 December 2021 at 21:07:45 UTC+2, Bart wrote:
> > > On 19/12/2021 18:40, Öö Tiib wrote:
> > > > On Sunday, 19 December 2021 at 01:38:17 UTC+2, Ben Bacarisse wrote:
> > > >> Öö Tiib <oot...@hot.ee> writes:
> > > >>
> > > >>> Lambdas are just syntax simplification of few things
> > > >>
> > > >> and later...
> > > >>
> > > >>> C++11 added several performance improvements like move semantics,
> > > >>> constexpr, noexcept, split concepts of trivial classes and standard layout
> > > >>> classes, even underlying type of enum. These are all better than syntax
> > > >>> sugar because these help to have more efficient product.
> > > >>
> > > >> Both of which are striking things to say, but there has already been too
> > > >> much discussion of C++ in comp.lang.c for me to feel happy to add more.
> > > >> (I think it's deliberate on BM's part.)
> > > >
> > > > I also realized that so I stopped answering to BM yesterday. Otherwise the
> > > > constexpr and underlying types to enums I would love to have in C too.
> > > > The constexpr lets to use most of language compile time. That is likely
> > > > tricky to implement from scratch but as gcc and clang both have it
> > > > anyway then why not.
> > > Yeah, in complicated compilers for a complicated language, so more
> > > complication will hardly be noticed!
> > >
> > > I have a problem with that feature: since this is user-code being run at
> > > compile-time, how long is a compiler prepared to spend executing such
> > > code? How worthwhile is that effort if it turns out that only a fraction
> > > of it, or none, is actually during any specific run?
> > It like every other feature depends on how programmer uses it. It can
> > compile 5 seconds longer but start program quicker or it can build
> > executable quicker but hang 5 seconds at start of every run. Or both,
> > or neither.
> >
> > If you are paranoid that your team members sabotage your project
> > with pointless compile time processing then reduce the maximum
> > steps of constexpr evaluation in your continuous integration server.
> >
> > However one who's clever enough can do it with preprocessor
> > metaprogramming and recursive #includes in C as easily as in
> > your C++ example. So better hire a team that you trust.
> >
> We had a case. Someone put in an innocent-seeming compile time
> const expression in C++. It worked on the development machines.
> Then when pushed to the CI server, it broke.
>
> It's the type of thing which can be quite hard for another programmer to
> fix quickly, because you've got to replace the functionality with a totally
> different construct.

Why to fix? Just reject the pull request. Or if it was accidentally merged to
some main development branch then revert.