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

Groups > comp.lang.c > #163780 > unrolled thread

Book or tutorial on standard C threads

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

Contents

  Book or tutorial on standard C threads Mehdi Amini <atorrses@gmail.com> - 2021-12-11 10:06 +0330
    Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-11 08:29 +0100
      Re: Book or tutorial on standard C threads gazelle@shell.xmission.com (Kenny McCormack) - 2021-12-13 08:12 +0000
        Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-14 17:41 +0100
    Re: Book or tutorial on standard C threads Thiago Adams <thiago.adams@gmail.com> - 2021-12-13 09:16 -0800
      Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-14 17:47 +0100
        Re: Book or tutorial on standard C threads scott@slp53.sl.home (Scott Lurndal) - 2021-12-14 17:13 +0000
          Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-14 18:43 +0100
            Re: Book or tutorial on standard C threads Guillaume <message@bottle.org> - 2021-12-14 19:23 +0100
              Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-14 20:16 +0100
            Re: Book or tutorial on standard C threads Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-12-15 04:02 -0800
              Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-15 17:53 +0100
                Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-15 17:26 +0000
                  Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-15 18:30 +0100
                  Re: Book or tutorial on standard C threads scott@slp53.sl.home (Scott Lurndal) - 2021-12-15 17:49 +0000
                    Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-15 19:19 +0100
                    Re: Book or tutorial on standard C threads "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-15 17:44 -0800
                  Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-15 20:23 +0100
                    Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-16 07:54 +0100
                      Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-16 14:16 +0000
                        Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-16 15:49 +0100
                          Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-16 15:57 +0000
                            Re: Book or tutorial on standard C threads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-16 17:03 +0000
                            Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-16 20:08 +0100
                              Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-16 20:48 +0000
                                Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-17 07:19 +0100
                        Re: Book or tutorial on standard C threads David Brown <david.brown@hesbynett.no> - 2021-12-16 17:24 +0100
                          Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-16 18:00 +0000
                            Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-16 20:06 +0100
                            Re: Book or tutorial on standard C threads David Brown <david.brown@hesbynett.no> - 2021-12-16 20:14 +0100
                              Re: Book or tutorial on standard C threads Öö Tiib <ootiib@hot.ee> - 2021-12-17 09:30 -0800
                                Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-17 19:06 +0100
                                  Re: Book or tutorial on standard C threads Öö Tiib <ootiib@hot.ee> - 2021-12-18 03:07 -0800
                                Re: Book or tutorial on standard C threads David Brown <david.brown@hesbynett.no> - 2021-12-18 18:33 +0100
                              Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-17 18:19 +0000
                                Re: Book or tutorial on standard C threads David Brown <david.brown@hesbynett.no> - 2021-12-18 18:45 +0100
                            Re: Book or tutorial on standard C threads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-16 21:45 +0000
                              Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-16 23:02 +0000
                                Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-18 13:45 +0100
                                  Re: Book or tutorial on standard C threads Öö Tiib <ootiib@hot.ee> - 2021-12-18 06:02 -0800
                                    Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-18 15:31 +0100
                                      Re: Book or tutorial on standard C threads Öö Tiib <ootiib@hot.ee> - 2021-12-18 07:12 -0800
                                        Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-18 16:45 +0100
                                    Re: Book or tutorial on standard C threads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-18 23:38 +0000
                                      Re: Book or tutorial on standard C threads Öö Tiib <ootiib@hot.ee> - 2021-12-19 10:40 -0800
                                        Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-19 19:07 +0000
                                          Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-19 20:17 +0100
                                          Re: Book or tutorial on standard C threads Öö Tiib <ootiib@hot.ee> - 2021-12-19 12:41 -0800
                                            Re: Book or tutorial on standard C threads Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-12-20 03:21 -0800
                                              Re: Book or tutorial on standard C threads Öö Tiib <ootiib@hot.ee> - 2021-12-20 09:39 -0800
                          Re: Book or tutorial on standard C threads scott@slp53.sl.home (Scott Lurndal) - 2021-12-16 18:32 +0000
                            Re: Book or tutorial on standard C threads David Brown <david.brown@hesbynett.no> - 2021-12-16 20:27 +0100
                            Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-16 20:33 +0100
                    Re: Book or tutorial on standard C threads Bart <bc@freeuk.com> - 2021-12-17 10:59 +0000
                      Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-17 13:08 +0100
                        Re: Book or tutorial on standard C threads scott@slp53.sl.home (Scott Lurndal) - 2021-12-17 16:25 +0000
                          Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-17 17:38 +0100
    Re: Book or tutorial on standard C threads "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-16 16:03 -0800
      Re: Book or tutorial on standard C threads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-17 00:12 +0000
        Re: Book or tutorial on standard C threads "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-16 17:05 -0800
          Re: Book or tutorial on standard C threads "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-16 17:07 -0800
    Re: Book or tutorial on standard C threads "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-19 17:23 -0800
      Re: Book or tutorial on standard C threads Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-20 07:35 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#163860

Am 16.12.2021 um 15:16 schrieb Bart:

> Which bit is the lambda? If I create a more compact version so that I 
> can see the whole thing more easily:

There is no way to have it more readable than with the lambdas.

> then push() just looks like an ordinary local function.

push() saves a lot of redundant code and it does make sense only locally
within that function - a perfect case for a lambda.


> What could be significantly improved are all those bitfield ops.
> Ideally you would use named bitfields within what is presumably
> a 32-bit  unsigned value, instead of all those mysterious shifts
> and masks.

I get the values from CPUID and it would make no sense to move that
to a bitfield'ed structure that because this should compile with
three compilers (MSVC, clang, g++) and they behave not absolutely
the same with bitfields.

> Those 0xFFF masks mixed with 16-bit shifts look suspicious until you 
> realise these are 12+4-bit fields in each half of a 32-bit value.

What I do is correct, look at the corresponding CPUID-documentation.

> Here even a simple GETBITS macro would improve both readability and 
> confidence that the code is correct.
> 

Macros are a no-go since they're global and often not debuggable
(depending on the IDE).

> So, it looks like your emphasis is different aspects: those elusive 
> lambdas (which doesn't help readability at all, unless it would be even 
> worse without them), rather than doing something about basic readability.

Of course the lambdas make the code more readable because they save
a huge amount of redundant code.

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

#163863

On 16/12/2021 14:49, Bonita Montero wrote:
> Am 16.12.2021 um 15:16 schrieb Bart:
> 
>> Which bit is the lambda? If I create a more compact version so that I 
>> can see the whole thing more easily:
> 
> There is no way to have it more readable than with the lambdas.
> 
>> then push() just looks like an ordinary local function.
> 
> push() saves a lot of redundant code and it does make sense only locally
> within that function - a perfect case for a lambda.

So which bit /is/ the lambda?!

> 
>> What could be significantly improved are all those bitfield ops.
>> Ideally you would use named bitfields within what is presumably
>> a 32-bit  unsigned value, instead of all those mysterious shifts
>> and masks.
> 
> I get the values from CPUID and it would make no sense to move that
> to a bitfield'ed structure that because this should compile with
> three compilers (MSVC, clang, g++) and they behave not absolutely
> the same with bitfields.

The docs for CPUID will be full of named bitfields; surely there is some 
way of naming those values instead of hard-coding meaningless numbers 
for shifts and masks.


>> Those 0xFFF masks mixed with 16-bit shifts look suspicious until you 
>> realise these are 12+4-bit fields in each half of a 32-bit value.
> 
> What I do is correct, look at the corresponding CPUID-documentation.
> 
>> Here even a simple GETBITS macro would improve both readability and 
>> confidence that the code is correct.

> Macros are a no-go since they're global and often not debuggable
> (depending on the IDE).


So, inlined functions, templates ... does C++ really have no better way 
of isolating a specific bitfield in A than using:

    (A>>x) & y

where x is the start bit, and y is so many 1-bits depending on the 
field's width?

Here's a much better approach using only C features:

https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/cpuid.h

>> So, it looks like your emphasis is different aspects: those elusive 
>> lambdas (which doesn't help readability at all, unless it would be 
>> even worse without them), rather than doing something about basic 
>> readability.
> 
> Of course the lambdas make the code more readable because they save
> a huge amount of redundant code.

How many more lines would this example have been without lambdas?

Because I'm sorry but I just can't see it. All I can see is that it uses 
CPUID to extract info into a bunch of registers. Then you extract some 
fields from those into an array of values.

Given a way to call CPUID, you don't need any special language features 
for what seems a rather trivial task.

It's also not clear whether this is real or made-up code, since the 
information returned using 0x80000006 doesn't correspond with what 
you're trying to extract. But then we don't know the mapping of regs[] 
to rcx etc, nor whether cpuid() is a real thing, as I had trouble 
finding some info on it.

BTW here's how I use cpuid [not C]:

     static [16]char id

     assem
         mov eax, 0
         cpuid
         mov [id],   ebx
         mov [id+4], edx
         mov [id+8], ecx
     end

     println "Processor ID =",id

This displays:

     Processor ID = AuthenticAMD

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

#163865

Bart <bc@freeuk.com> writes:

> On 16/12/2021 14:49, Bonita Montero wrote:
>> Am 16.12.2021 um 15:16 schrieb Bart:
>> 
>>> Which bit is the lambda? If I create a more compact version so that I can see the whole thing more easily:
>> There is no way to have it more readable than with the lambdas.
>> 
>>> then push() just looks like an ordinary local function.
>> push() saves a lot of redundant code and it does make sense only locally
>> within that function - a perfect case for a lambda.
>
> So which bit /is/ the lambda?!

The bit that starts [&], followed by a function header (with C++'s new
-> return_type syntax) and a block.  I.e. most of the first line and all
but two lines of the rest of the posted code..

-- 
Ben.

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

#163872

Am 16.12.2021 um 16:57 schrieb Bart:

> The docs for CPUID will be full of named bitfields; surely there is some 
> way of naming those values instead of hard-coding meaningless numbers 
> for shifts and masks.

Bitfields aren't absolutely compatible among x86-compilers.
So I extract them manuall.

> How many more lines would this example have been without lambdas?

Each push would have to be expanded and gatherTlbs would be twice.
That's an enormous amount of code.

Rest of your nonsense unread.

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

#163881

On 16/12/2021 19:08, Bonita Montero wrote:
> Am 16.12.2021 um 16:57 schrieb Bart:
> 
>> The docs for CPUID will be full of named bitfields; surely there is 
>> some way of naming those values instead of hard-coding meaningless 
>> numbers for shifts and masks.
> 
> Bitfields aren't absolutely compatible among x86-compilers.
> So I extract them manuall.
> 
>> How many more lines would this example have been without lambdas?
> 
> Each push would have to be expanded and gatherTlbs would be twice.
> That's an enormous amount of code.

It's already a considerable amount of code, for a seemingly simple task. 
Maybe enough that you can't see the wood for the trees.

gatherTLBs() is already called twice; all those push() calls have to be 
done once just to count how many TLBS, then again for real.

And all to reserve a size for tlbs which is pointless since the size is 
so small; it will be 8 or 12. Either start from empty, or reserve 8 or 
12 slots.

Each push() call also includes an 'update' parameter, not necessary 
since it can see the update parameter of the enclosing gatherTLBs function.

gatherTLBs() seems to be yet another lambda, the purpose of which is 
unclear from the supplied context.

It's not clear where tlbs comes from; a global visible to gatherTLBs?

What is clear that you are just using this stuff because you can. The 
result is code more elaborate than necessary and using more advanced 
features than necessary.

Given access to the cpuid() routine used here, a version in C could 
easily be simpler.

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

#163903

Am 16.12.2021 um 21:48 schrieb Bart:

> And all to reserve a size for tlbs which is pointless since the size is 
> so small; it will be 8 or 12. Either start from empty, or reserve 8 or 
> 12 slots.

Doesn't matter. It's just a little effort to have it called twice
and it saves some CPU-time for sure.

> Each push() call also includes an 'update' parameter, not necessary 
> since it can see the update parameter of the enclosing gatherTLBs function.

That's a matter of taste.

> gatherTLBs() seems to be yet another lambda, the purpose of which is 
> unclear from the supplied context.

It's called twice and therefore a lamda makes sense.

> It's not clear where tlbs comes from; a global visible to gatherTLBs?

You don't know the code where gatherTLBs is embedded in.

> What is clear that you are just using this stuff because you can.

No, because it safes a huge amount of code and its the fastest solution.

> Given access to the cpuid() routine used here, a version in C could 
> easily be simpler.

No, for sure not.

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

#163864

On 16/12/2021 15:16, Bart wrote:
> On 16/12/2021 06:54, Bonita Montero wrote:
>> Here's another good example of using long lambdas:
>>
>>          auto gatherTLBs = [&]( bool update ) -> size_t
>>          {
>>              size_t nTLBs = 0;
>>              auto push = [&]( bool l2, bool code, bool _4k, bool
>> _2M4M, bool _1G, unsigned n, unsigned ways, bool update )
>>              {

<snip>

> 
> So, it looks like your emphasis is different aspects: those elusive
> lambdas (which doesn't help readability at all, unless it would be even
> worse without them), rather than doing something about basic readability.

The lambdas here are nothing more nor less than function-local
functions.  Neither C nor C++ has support for local functions (unlike
Pascal, Ada, and many other languages - including gcc extended C).
Lambdas can certainly be convenient for that, and are safer, easier and
better scoped than using macros.

(Readability is in the eye of the beholder, and I'd rather not comment
here.  I am also not commenting on the code itself, or how it could have
been written.)

> 
> Those first 5 Bool parameters for push also look like they are ripe for
> conversion to a single flag parameter containing 5 single-bit fields
> (Just Or-ing named bit-masks would be better.)
> 
> Remember your original looked like this:
> 
>     push( false, false, true, false, false, ...
> 
> What do each of these signify? At least, if using multiple parameters,
> use keyword parameters combined with a default value, such as false,
> then this example can become:
> 
>     push(..., FlagA:true)
> 
> (Keyword parameters go after positional ones.) Again I don't know what
> these mean so can't give a more useful name.
> 
> (Does C++ have keyword parameters? It looks like it doesn't.)
> 
> 

No, C++ does not have keyword parameters.  It is something that comes up
again and again in propositions, requests and suggestions, and hopefully
it will be included eventually.  But there are large number of
possibilities and choices involved that make it surprisingly difficult
to pin down exactly how keyword parameters could be added to the language.

But C++ /does/ have several alternatives to a long list of booleans like
this.  The simplest would be:

enum class FlagA { True, False };
enum class FlagB { True, False };

void foo(FlagA a, FlagB b);

void bar(void) {
    foo(FlagA::True, FlagB::False);
}

You can't get this wrong and call "foo(FlagB::True, FlagA::False)" - the
compiler would spot the error.  Strong types like this for parameters
can help if you have a long parameter list.

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

#163867

On 16/12/2021 16:24, David Brown wrote:
> On 16/12/2021 15:16, Bart wrote:
>> On 16/12/2021 06:54, Bonita Montero wrote:
>>> Here's another good example of using long lambdas:
>>>
>>>           auto gatherTLBs = [&]( bool update ) -> size_t
>>>           {
>>>               size_t nTLBs = 0;
>>>               auto push = [&]( bool l2, bool code, bool _4k, bool
>>> _2M4M, bool _1G, unsigned n, unsigned ways, bool update )
>>>               {
> 
> <snip>
> 
>>
>> So, it looks like your emphasis is different aspects: those elusive
>> lambdas (which doesn't help readability at all, unless it would be even
>> worse without them), rather than doing something about basic readability.
> 
> The lambdas here are nothing more nor less than function-local
> functions.  Neither C nor C++ has support for local functions (unlike
> Pascal, Ada, and many other languages - including gcc extended C).
> Lambdas can certainly be convenient for that, and are safer, easier and
> better scoped than using macros.

So the lambda here is the local 'function' that includes that '[&]` 
(according to BB)?

That's not what I'd think of as a 'lambda', which would be a function 
(parameter-spec and body) embedded in an expression - code to be 
evaluated later not as encountered.

I'm surprised that even gnu C++ doesn't have local functions (or does it?).

In that case a more suitable and more useful feature would have been 
local functions.

(Which I used to implemented, but I kept them simple to avoid problems 
with accessing or capturing surrounding variables: accesses to 
stack-allocated variables of the enclosing function(s) were banned; but 
everything else was accessible.

To implement BM's example, 'update' and 'nTLBs' would need to be static, 
or copied to a static variable.

I no longer have them because they were never used, and they caused 
problems when an 'end' was left out, as that was only detected at the 
end of the file rather than at the start of the next function, which was 
interpreted as nested.)

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

#163871

Am 16.12.2021 um 19:00 schrieb Bart:

> To implement BM's example, 'update' and 'nTLBs' would need to be static, 
> or copied to a static variable.

No, that would be an unclean solution.

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

#163873

On 16/12/2021 19:00, Bart wrote:
> On 16/12/2021 16:24, David Brown wrote:
>> On 16/12/2021 15:16, Bart wrote:
>>> On 16/12/2021 06:54, Bonita Montero wrote:
>>>> Here's another good example of using long lambdas:
>>>>
>>>>           auto gatherTLBs = [&]( bool update ) -> size_t
>>>>           {
>>>>               size_t nTLBs = 0;
>>>>               auto push = [&]( bool l2, bool code, bool _4k, bool
>>>> _2M4M, bool _1G, unsigned n, unsigned ways, bool update )
>>>>               {
>>
>> <snip>
>>
>>>
>>> So, it looks like your emphasis is different aspects: those elusive
>>> lambdas (which doesn't help readability at all, unless it would be even
>>> worse without them), rather than doing something about basic
>>> readability.
>>
>> The lambdas here are nothing more nor less than function-local
>> functions.  Neither C nor C++ has support for local functions (unlike
>> Pascal, Ada, and many other languages - including gcc extended C).
>> Lambdas can certainly be convenient for that, and are safer, easier and
>> better scoped than using macros.
> 
> 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!

> 
> That's not what I'd think of as a 'lambda', which would be a function
> (parameter-spec and body) embedded in an expression - code to be
> evaluated later not as encountered.

Yes, that is also a way to use lambdas.  They can do many things.  They
are popular as callbacks, or for when a function requires a
function-like object as a parameter (such as a sorting function that
needs a comparison function), as you can define the function where you
need it rather than somewhere else in the code.  They can also have
captures, which are useful at times.  And a function can return a
lambda, meaning that you now have the possibility of a functional
programming style.  (An example would be if you have "filter" functions
- you could have a "compose" function that takes two filter functions as
parameters and returns a lambda that combines them.)

But you can also use them as "normal" function definitions, except that
it is possible to use them in smaller scopes than file, namespace or as
class methods.  So the following are approximately the same:

	int foo(int x, int y) { return x + y; }
	auto foo(int x, int y) { return x + y; }
	auto foo(int x, int y) -> int { return x + y; }

	auto foo = [](int x, int y) { return x + y; }
	auto foo = [](int x, int y) -> int { return x + y; }

If you are familiar with lambdas in Python, they are quite similar in
C++ - except that Python uses the keyword "lambda" and the way captures
is done is different.  If you are familiar with Lua, all function
definitions are actually done as lambdas, with "normal" function
definitions being syntactic sugar for assigning a lambda to a name.

> 
> I'm surprised that even gnu C++ doesn't have local functions (or does it?).

<https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html>

They are supported in C (I think the compiler support was made when gcc
support for Ada was introduced, and then adding them as a C extension
was easy).  They are not supported in C++, which is fine - you don't
need them when you have lambdas as lambdas cover everything you can do
with local functions, plus much more.

> 
> In that case a more suitable and more useful feature would have been
> local functions.
> 

Eh, no.  Lambdas are more general.  (But in a more limited and simpler
language, nested function support might be enough, and it is almost
certainly easier to implement in the compiler.)

> (Which I used to implemented, but I kept them simple to avoid problems
> with accessing or capturing surrounding variables: accesses to
> stack-allocated variables of the enclosing function(s) were banned; but
> everything else was accessible.
> 
> To implement BM's example, 'update' and 'nTLBs' would need to be static,
> or copied to a static variable.
> 
> I no longer have them because they were never used, and they caused
> problems when an 'end' was left out, as that was only detected at the
> end of the file rather than at the start of the next function, which was
> interpreted as nested.)

I can't say I ever used nested functions more than once or twice when
using languages that have always supported them (such as Pascal).  You
quickly end up with too much in the outer function, and too much
indentation.  And if the language requires (or encourages) a style of
defining things at the start of the function definition, there is often
little to be gained compared to just making the nested function a
file-scope function.  With C++ (or Python), it's easy and natural to
make the lambdas just where you need them, making them more useful (to
me, at least).

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

#163922

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.

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

#163924

Am 17.12.2021 um 18:30 schrieb Öö Tiib:
> 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.

Yes, more readable because lambdas could save a lot of redundant code.

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

#163933

On Friday, 17 December 2021 at 20:07:08 UTC+2, Bonita Montero wrote:
> Am 17.12.2021 um 18:30 schrieb Öö Tiib: 
> > 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.
> Yes, more readable because lambdas could save a lot of redundant code.

These were designed for that purpose. But my bots running over actual
code bases report that lambdas in actual reality are most frequent new
containers of copy-pasta. 

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

#163966

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

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

#163925

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.


>> I no longer have them because they were never used, and they caused
>> problems when an 'end' was left out, as that was only detected at the
>> end of the file rather than at the start of the next function, which was
>> interpreted as nested.)
> 
> I can't say I ever used nested functions more than once or twice when
> using languages that have always supported them (such as Pascal).  You
> quickly end up with too much in the outer function, and too much
> indentation.  And if the language requires (or encourages) a style of
> defining things at the start of the function definition, there is often
> little to be gained compared to just making the nested function a
> file-scope function.  With C++ (or Python), it's easy and natural to
> make the lambdas just where you need them, making them more useful (to
> me, at least).

While I no longer support normal nested functions, I still allow 
function definitions inside records (ie. structs in C, or classes in 
C++, where they might be called methods).

Those can also be nested (although name resolution across more than one 
level needs attention).

That serves to encapsulate a bunch of related functions, isolated from 
the rest of the file, and can be used with no need to create an instance 
of the record or call them as methods.

I tried to do the same with C++ classes, but I don't know the language 
and got tied up in knots trying to make it work.

I wanted to show another approach to using nested functions and lambdas. 
If C++ can't in fact do what I wanted, then it /could/ have done.

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

#163968

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

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

#163886

Bart <bc@freeuk.com> writes:

> On 16/12/2021 16:24, David Brown wrote:
>> On 16/12/2021 15:16, Bart wrote:
>>> On 16/12/2021 06:54, Bonita Montero wrote:
>>>> Here's another good example of using long lambdas:
>>>>
>>>>           auto gatherTLBs = [&]( bool update ) -> size_t
>>>>           {
>>>>               size_t nTLBs = 0;
>>>>               auto push = [&]( bool l2, bool code, bool _4k, bool
>>>> _2M4M, bool _1G, unsigned n, unsigned ways, bool update )
>>>>               {
>> <snip>
>> 
>>>
>>> So, it looks like your emphasis is different aspects: those elusive
>>> lambdas (which doesn't help readability at all, unless it would be even
>>> worse without them), rather than doing something about basic readability.
>>
>> The lambdas here are nothing more nor less than function-local
>> functions.  Neither C nor C++ has support for local functions (unlike
>> Pascal, Ada, and many other languages - including gcc extended C).
>> Lambdas can certainly be convenient for that, and are safer, easier and
>> better scoped than using macros.
>
> So the lambda here is the local 'function' that includes that '[&]`
> (according to BB)?
>
> That's not what I'd think of as a 'lambda', which would be a function
> (parameter-spec and body) embedded in an expression - code to be
> evaluated later not as encountered.

The lambda posted /was/ embedded in an expression.  Sure, it was the
entire expression used to initialise what will be, in effect, a name for
an anonymous, but if you don't have scoped function declarations, that's
the way to do it.

> I'm surprised that even gnu C++ doesn't have local functions (or does
> it?).

gnu C does, but not gnu C++.  The C++ lambda solution is standard,
though.

-- 
Ben.

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

#163890

On 16/12/2021 21:45, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> On 16/12/2021 16:24, David Brown wrote:
>>> On 16/12/2021 15:16, Bart wrote:
>>>> On 16/12/2021 06:54, Bonita Montero wrote:
>>>>> Here's another good example of using long lambdas:
>>>>>
>>>>>            auto gatherTLBs = [&]( bool update ) -> size_t
>>>>>            {
>>>>>                size_t nTLBs = 0;
>>>>>                auto push = [&]( bool l2, bool code, bool _4k, bool
>>>>> _2M4M, bool _1G, unsigned n, unsigned ways, bool update )
>>>>>                {
>>> <snip>
>>>
>>>>
>>>> So, it looks like your emphasis is different aspects: those elusive
>>>> lambdas (which doesn't help readability at all, unless it would be even
>>>> worse without them), rather than doing something about basic readability.
>>>
>>> The lambdas here are nothing more nor less than function-local
>>> functions.  Neither C nor C++ has support for local functions (unlike
>>> Pascal, Ada, and many other languages - including gcc extended C).
>>> Lambdas can certainly be convenient for that, and are safer, easier and
>>> better scoped than using macros.
>>
>> So the lambda here is the local 'function' that includes that '[&]`
>> (according to BB)?
>>
>> That's not what I'd think of as a 'lambda', which would be a function
>> (parameter-spec and body) embedded in an expression - code to be
>> evaluated later not as encountered.
> 
> The lambda posted /was/ embedded in an expression.  Sure, it was the
> entire expression used to initialise what will be, in effect, a name for
> an anonymous, but if you don't have scoped function declarations, that's
> the way to do it.
> 
>> I'm surprised that even gnu C++ doesn't have local functions (or does
>> it?).
> 
> gnu C does, but not gnu C++.  The C++ lambda solution is standard,
> though.


I got the impression that BM is using lambdas because nested functions 
don't exist. So it's not quite as surprising that they would use them 
heavily.

Although I wouldn't bother even with nested functions for that example code.

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

#163939

Am 17.12.2021 um 00:02 schrieb Bart:
> On 16/12/2021 21:45, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 16/12/2021 16:24, David Brown wrote:
>>>> On 16/12/2021 15:16, Bart wrote:
>>>>> On 16/12/2021 06:54, Bonita Montero wrote:
>>>>>> Here's another good example of using long lambdas:
>>>>>>
>>>>>>            auto gatherTLBs = [&]( bool update ) -> size_t
>>>>>>            {
>>>>>>                size_t nTLBs = 0;
>>>>>>                auto push = [&]( bool l2, bool code, bool _4k, bool
>>>>>> _2M4M, bool _1G, unsigned n, unsigned ways, bool update )
>>>>>>                {
>>>> <snip>
>>>>
>>>>>
>>>>> So, it looks like your emphasis is different aspects: those elusive
>>>>> lambdas (which doesn't help readability at all, unless it would be 
>>>>> even
>>>>> worse without them), rather than doing something about basic 
>>>>> readability.
>>>>
>>>> The lambdas here are nothing more nor less than function-local
>>>> functions.  Neither C nor C++ has support for local functions (unlike
>>>> Pascal, Ada, and many other languages - including gcc extended C).
>>>> Lambdas can certainly be convenient for that, and are safer, easier and
>>>> better scoped than using macros.
>>>
>>> So the lambda here is the local 'function' that includes that '[&]`
>>> (according to BB)?
>>>
>>> That's not what I'd think of as a 'lambda', which would be a function
>>> (parameter-spec and body) embedded in an expression - code to be
>>> evaluated later not as encountered.
>>
>> The lambda posted /was/ embedded in an expression.  Sure, it was the
>> entire expression used to initialise what will be, in effect, a name for
>> an anonymous, but if you don't have scoped function declarations, that's
>> the way to do it.
>>
>>> I'm surprised that even gnu C++ doesn't have local functions (or does
>>> it?).
>>
>> gnu C does, but not gnu C++.  The C++ lambda solution is standard,
>> though.
> 
> 
> I got the impression that BM is using lambdas because nested functions 
> don't exist. So it's not quite as surprising that they would use them 
> heavily.
> 
> Although I wouldn't bother even with nested functions for that example 
> code.

Lambdas are a great relief and I think they're the most importand part 
of C++11.

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

#163943

On Saturday, 18 December 2021 at 14:45:15 UTC+2, Bonita Montero wrote:
> Am 17.12.2021 um 00:02 schrieb Bart: 
> > On 16/12/2021 21:45, Ben Bacarisse wrote: 
> >> Bart <b...@freeuk.com> writes: 
> >> 
> >>> On 16/12/2021 16:24, David Brown wrote: 
> >>>> On 16/12/2021 15:16, Bart wrote: 
> >>>>> On 16/12/2021 06:54, Bonita Montero wrote: 
> >>>>>> Here's another good example of using long lambdas: 
> >>>>>> 
> >>>>>>            auto gatherTLBs = [&]( bool update ) -> size_t 
> >>>>>>            { 
> >>>>>>                size_t nTLBs = 0; 
> >>>>>>                auto push = [&]( bool l2, bool code, bool _4k, bool 
> >>>>>> _2M4M, bool _1G, unsigned n, unsigned ways, bool update ) 
> >>>>>>                { 
> >>>> <snip> 
> >>>> 
> >>>>> 
> >>>>> So, it looks like your emphasis is different aspects: those elusive 
> >>>>> lambdas (which doesn't help readability at all, unless it would be 
> >>>>> even 
> >>>>> worse without them), rather than doing something about basic 
> >>>>> readability. 
> >>>> 
> >>>> The lambdas here are nothing more nor less than function-local 
> >>>> functions.  Neither C nor C++ has support for local functions (unlike 
> >>>> Pascal, Ada, and many other languages - including gcc extended C). 
> >>>> Lambdas can certainly be convenient for that, and are safer, easier and 
> >>>> better scoped than using macros. 
> >>> 
> >>> So the lambda here is the local 'function' that includes that '[&]` 
> >>> (according to BB)? 
> >>> 
> >>> That's not what I'd think of as a 'lambda', which would be a function 
> >>> (parameter-spec and body) embedded in an expression - code to be 
> >>> evaluated later not as encountered. 
> >> 
> >> The lambda posted /was/ embedded in an expression.  Sure, it was the 
> >> entire expression used to initialise what will be, in effect, a name for 
> >> an anonymous, but if you don't have scoped function declarations, that's 
> >> the way to do it. 
> >> 
> >>> I'm surprised that even gnu C++ doesn't have local functions (or does 
> >>> it?). 
> >> 
> >> gnu C does, but not gnu C++.  The C++ lambda solution is standard, 
> >> though. 
> > 
> > 
> > I got the impression that BM is using lambdas because nested functions 
> > don't exist. So it's not quite as surprising that they would use them 
> > heavily. 
> > 
> > Although I wouldn't bother even with nested functions for that example 
> > code.
> Lambdas are a great relief and I think they're the most importand part 
> of C++11.

Lambdas are just syntax simplification of few things
and syntax improvements are not comparable with major performance
improvements that C++11 added. The amount of code saved and confusion
added is comparable with effect of auto.

From syntax sugar improvements the range-based-for and variadic 
templates are also far better than lambdas because these make code
more elegant without adding any weird garbage or confusion.

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.

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web