David Brown <david.brown@hesbynett.no> writes:

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

Although 'true' and 'false' by themselves don't transmit anything useful
at the call site.

enum class DMAtype { Flat, ScatterGather, None };
enum class ERRmode { Recover, Abort, Ignore };

foo(DMAType::Flat, ERRmode::Recover);

Enhances readability and maintainability.

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.

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.

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

On 16/12/2021 19:32, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> 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.
>
> Although 'true' and 'false' by themselves don't transmit anything useful
> at the call site.
>
> enum class DMAtype { Flat, ScatterGather, None };
> enum class ERRmode { Recover, Abort, Ignore };
>
> foo(DMAType::Flat, ERRmode::Recover);
>
> Enhances readability and maintainability.
>

Of course. This was just an example of a relatively small improvement.
There are other ways to do better. (And "True" and "False" may be
entirely sufficient if the type name is good enough -
EnableAutoMode::True is hard to better.)

Am 16.12.2021 um 19:32 schrieb Scott Lurndal:
> David Brown <david.brown@hesbynett.no> writes:
>
>> 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.
>
> Although 'true' and 'false' by themselves don't transmit anything useful
> at the call site.
>
> enum class DMAtype { Flat, ScatterGather, None };
> enum class ERRmode { Recover, Abort, Ignore };
>
> foo(DMAType::Flat, ERRmode::Recover);
>
> Enhances readability and maintainability.

I mostly use enums in my own classes and there I don't use scoped
enums. It's just cumbersome to type ClassName::EnumName::EnumValue.
But I would also scope global enums.

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.

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.

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.

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 ?

Call me old fashioned, but I still love this simple type of setup...
_____________________
#include <iostream>
#include <thread>
#include <atomic>
#include <algorithm>

struct ct_shared_state
{ std::atomic<int> m_foo;
};

void
ct_thread(ct_shared_state& shared)
{ shared.m_foo.fetch_add(1, std::memory_order_relaxed);
}

#define CT_THREADS 32

int main()
{ std::cout << "Hello World!\n\n";
std::cout.flush();

ct_shared_state shared_state = { { 1 } };

{
std::thread threads[CT_THREADS];

for (unsigned int i = 0; i < CT_THREADS; ++i)
{
threads[i] = std::thread(ct_thread, std::ref(shared_state));
}

for (unsigned int i = 0; i < CT_THREADS; ++i)
{
threads[i].join();
}
}

std::cout << shared_state.m_foo.load(std::memory_order_relaxed) *
11 + 303;

std::cout << "\n\nFin!\n\n";

return 0;
} _____________________

666

;^)

Old school. ;^)

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> 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 ?
>
> Call me old fashioned, but I still love this simple type of setup...
> _____________________
> #include <iostream>

The OP is asking about C.

--
Ben.

On 12/16/2021 4:12 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>> 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 ?
>>
>> Call me old fashioned, but I still love this simple type of setup...
>> _____________________
>> #include <iostream>
>
> The OP is asking about C.
>

Indeed. Fwiw, the last time I tried to get a C11 compiler to work was in
Pelles C:

http://www.smorgasbordet.com/pellesc

On 12/16/2021 5:05 PM, Chris M. Thomasson wrote:
> On 12/16/2021 4:12 PM, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>
>>> 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 ?
>>>
>>> Call me old fashioned, but I still love this simple type of setup...
>>> _____________________
>>> #include <iostream>
>>
>> The OP is asking about C.
>>
>
> Indeed. Fwiw, the last time I tried to get a C11 compiler to work was in
> Pelles C:
>
> http://www.smorgasbordet.com/pellesc
>

read all:

https://groups.google.com/g/comp.lang.c/c/gtD8weVPIjg

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.

On 15/12/2021 19:23, Bonita Montero wrote:
> Am 15.12.2021 um 18:26 schrieb Bart:
>> On 15/12/2021 16:53, Bonita Montero wrote:
>>> Am 15.12.2021 um 13:02 schrieb Malcolm McLean:
>>>> On Tuesday, 14 December 2021 at 17:43:28 UTC, Bonita Montero wrote:
>>>>>> Simply? If your thread function is so simple that it makes
>>>>>> sense to write it as a lambda, you probably should not be
>>>>>> using threads.
>>>>> You're so silly to think lambdas are suitable only for simple things.
>>>>> I regulary use complex lambdas as jthread-"functions" which inherit
>>>>> the initiators context through [&].
>>>>>
>>>> I write mainly procedural C++. But it's easier to pass a trivial little
>>>> lambda to std::sort than to write a free-standing comparison function.
>>>> I rarely write code which accepts lambdas, just as I rarely write code
>>>> which declares templates, though I call such code quite frequently.
>>>
>>> I even use often templated lambdas.
>>
>> You would!
>>
>> You just /have/ to use the most elaborate toys at your disposal -
>> preferably as many at the same time as possible - and combine them in
>> ways that make people's heads spin.
>>
>> And yet you're always pushing the agenda that C++ somehow makes
>> everything a piece of cake!
>
>
> That's an example of my lambda-style:
>
>         auto buildChain = [&]<CmdLineParams::type_t Type>( bool
> smtThreaded, unsigned toThread )
>         {
>             auto updateStarts = [&]<typename MappingFn>( MappingFn
> mappingFn )
>                 requires requires( MappingFn mappingFn, size_t i )
>                 {
>                     { mappingFn( i ) } -> same_as<size_t>;
>                 }
>             {
>                 for( unsigned nThreads = 1; nThreads <= toThread;
> ++nThreads )
>                 {
>                     vector<link_t *> &starts = chainStarts[nThreads - 1];
>                     double gap = (double)(ptrdiff_t)n / (int)nThreads;
>                     for( unsigned t = 0; t != nThreads; ++t )
>                         starts[t] = &links[mappingFn(
> (ptrdiff_t)((int)t * gap) )];
>                 }
>             };
>             if constexpr( Type == CmdLineParams::LINEAR || Type ==
> CmdLineParams::XLINEAR )
>             {
>                 auto linearConcat = [&]<typename MappingFn>( MappingFn
> mappingFn )
>                     requires requires( MappingFn mappingFn, size_t i )
>                     {
>                         { mappingFn( i ) } -> same_as<size_t>;
>                     }
>                 {
>                     for( size_t i = 0; i != n; ++i )
>                         links[i].next = &links[mappingFn( mappingFn( i
> ) + 1 & idxMask)];
>                 };
>                 if constexpr( Type == CmdLineParams::LINEAR )
>                 {
>                     auto directMap = []( size_t i ) { return i; };
>                     linearConcat( directMap );
>                     updateStarts( directMap );
>                 }
>                 else
>                 {
>                     size_t inverter = (size_t)0x5555555555555555u &
> idxMask;
>                     auto invertedMap = [&]( size_t i ) { return i ^
> inverter; };
>                     linearConcat( invertedMap );
>                     updateStarts( invertedMap );
>                 }
>                 return;
>             }
>             unsigned l2ThrTlbBits = l2TlbBits - (unsigned)(smtThreaded
> && l2TlbBits),
>                      l1ThrTlbBits = l1TlbBits - (unsigned)(smtThreaded
> && l1TlbBits);
>             unsigned l1Bits, l2Bits, outerBits;
>             size_t l2Mask, outerMask;
>             auto maskFromBits = []( unsigned bits ) -> size_t { return
> ((size_t)1 << bits) - 1; };
>             if constexpr( Type == CmdLineParams::TLB_RANDOM )
>                 if( bits > l2ThrTlbBits + pageBits )
>                     outerBits = bits - (l2ThrTlbBits + pageBits),
>                     outerMask = maskFromBits( outerBits ),
>                     l2Bits = l2ThrTlbBits - l1ThrTlbBits,
>                     l2Mask = maskFromBits( l2Bits ),
>                     l1Bits = l1ThrTlbBits + pageBits - linkBits;
>                 else if( bits > l1ThrTlbBits + pageBits )
>                     outerBits = 0,
>                     outerMask = 0,
>                     l2Bits = bits - (l1ThrTlbBits + pageBits),
>                     l2Mask = maskFromBits( l2Bits ),
>                     l1Bits = l1ThrTlbBits + pageBits - linkBits;
>                 else
>                     outerBits = 0,
>                     outerMask = 0,
>                     l2Bits = 0,
>                     l2Mask = 0,
>                     l1Bits = bits - linkBits;
>             else
>                 l1Bits = bits - linkBits;
>             auto flipIndex = [&]( size_t i ) -> size_t
>             {
>                 static unsigned const SZT_BITS = sizeof(size_t) *
> CHAR_BIT;
>                 size_t rL1 = reverseBits( i ) >> SZT_BITS - l1Bits;
>                 if constexpr( Type != CmdLineParams::TLB_RANDOM )
>                     return rL1;
>                 size_t rL2 = reverseBits( i >> l1Bits ) >> SZT_BITS -
> l2Bits & l2Mask,
>                        rOuter = reverseBits( i >> l2Bits + l1Bits ) >>
> SZT_BITS - outerBits & outerMask;
>                 return rL1 + (rL2 << l1Bits) + (rOuter << l2Bits +
> l1Bits);
>             };
>             for( size_t rI = 0; rI != n; ++rI )
>                 links[rI].next = &links[flipIndex( flipIndex( rI ) + 1
> & idxMask )];
>             updateStarts( flipIndex );
>         };
>
> Without lambdas and even more templated lambdas the code
> would become very complicated.

Now that I know which bits are lambdas, and now that I know that you
mainly use lambdas to implement local functions, a missing C++ feature,
this code isn't really that remarkable.

It's just overly elaborate which is typical of your coding style.

Am 17.12.2021 um 11:59 schrieb Bart:

>> That's an example of my lambda-style:
>>
>>          auto buildChain = [&]<CmdLineParams::type_t Type>( bool
>> smtThreaded, unsigned toThread )
>>          {
>>              auto updateStarts = [&]<typename MappingFn>( MappingFn
>> mappingFn )
>>                  requires requires( MappingFn mappingFn, size_t i )
>>                  {
>>                      { mappingFn( i ) } -> same_as<size_t>;
>>                  }
>>              {
>>                  for( unsigned nThreads = 1; nThreads <= toThread;
>> ++nThreads )
>>                  {
>>                      vector<link_t *> &starts = chainStarts[nThreads -
>> 1];
>>                      double gap = (double)(ptrdiff_t)n / (int)nThreads;
>>                      for( unsigned t = 0; t != nThreads; ++t )
>>                          starts[t] = &links[mappingFn(
>> (ptrdiff_t)((int)t * gap) )];
>>                  }
>>              };
>>              if constexpr( Type == CmdLineParams::LINEAR || Type ==
>> CmdLineParams::XLINEAR )
>>              {
>>                  auto linearConcat = [&]<typename MappingFn>(
>> MappingFn mappingFn )
>>                      requires requires( MappingFn mappingFn, size_t i )
>>                      {
>>                          { mappingFn( i ) } -> same_as<size_t>;
>>                      }
>>                  {
>>                      for( size_t i = 0; i != n; ++i )
>>                          links[i].next = &links[mappingFn( mappingFn(
>> i ) + 1 & idxMask)];
>>                  };
>>                  if constexpr( Type == CmdLineParams::LINEAR )
>>                  {
>>                      auto directMap = []( size_t i ) { return i; };
>>                      linearConcat( directMap );
>>                      updateStarts( directMap );
>>                  }
>>                  else
>>                  {
>>                      size_t inverter = (size_t)0x5555555555555555u &
>> idxMask;
>>                      auto invertedMap = [&]( size_t i ) { return i ^
>> inverter; };
>>                      linearConcat( invertedMap );
>>                      updateStarts( invertedMap );
>>                  }
>>                  return;
>>              }
>>              unsigned l2ThrTlbBits = l2TlbBits -
>> (unsigned)(smtThreaded && l2TlbBits),
>>                       l1ThrTlbBits = l1TlbBits -
>> (unsigned)(smtThreaded && l1TlbBits);
>>              unsigned l1Bits, l2Bits, outerBits;
>>              size_t l2Mask, outerMask;
>>              auto maskFromBits = []( unsigned bits ) -> size_t {
>> return ((size_t)1 << bits) - 1; };
>>              if constexpr( Type == CmdLineParams::TLB_RANDOM )
>>                  if( bits > l2ThrTlbBits + pageBits )
>>                      outerBits = bits - (l2ThrTlbBits + pageBits),
>>                      outerMask = maskFromBits( outerBits ),
>>                      l2Bits = l2ThrTlbBits - l1ThrTlbBits,
>>                      l2Mask = maskFromBits( l2Bits ),
>>                      l1Bits = l1ThrTlbBits + pageBits - linkBits;
>>                  else if( bits > l1ThrTlbBits + pageBits )
>>                      outerBits = 0,
>>                      outerMask = 0,
>>                      l2Bits = bits - (l1ThrTlbBits + pageBits),
>>                      l2Mask = maskFromBits( l2Bits ),
>>                      l1Bits = l1ThrTlbBits + pageBits - linkBits;
>>                  else
>>                      outerBits = 0,
>>                      outerMask = 0,
>>                      l2Bits = 0,
>>                      l2Mask = 0,
>>                      l1Bits = bits - linkBits;
>>              else
>>                  l1Bits = bits - linkBits;
>>              auto flipIndex = [&]( size_t i ) -> size_t
>>              {
>>                  static unsigned const SZT_BITS = sizeof(size_t) *
>> CHAR_BIT;
>>                  size_t rL1 = reverseBits( i ) >> SZT_BITS - l1Bits;
>>                  if constexpr( Type != CmdLineParams::TLB_RANDOM )
>>                      return rL1;
>>                  size_t rL2 = reverseBits( i >> l1Bits ) >> SZT_BITS -
>> l2Bits & l2Mask,
>>                         rOuter = reverseBits( i >> l2Bits + l1Bits )
>> >> SZT_BITS - outerBits & outerMask;
>>                  return rL1 + (rL2 << l1Bits) + (rOuter << l2Bits +
>> l1Bits);
>>              };
>>              for( size_t rI = 0; rI != n; ++rI )
>>                  links[rI].next = &links[flipIndex( flipIndex( rI ) +
>> 1 & idxMask )];
>>              updateStarts( flipIndex );
>>          };
>>
>> Without lambdas and even more templated lambdas the code
>> would become very complicated.
>
> Now that I know which bits are lambdas, and now that I know that you
> mainly use lambdas to implement local functions, a missing C++ feature,
> this code isn't really that remarkable.

Lambdas are local functions and make the code _much_ more
readable if you use them properly - like in the above example.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 17.12.2021 um 11:59 schrieb Bart:
>
>>> That's an example of my lambda-style:
>>>
>>>          auto buildChain = [&]<CmdLineParams::type_t Type>( bool
>>> smtThreaded, unsigned toThread )
>>>          {
>>>              auto updateStarts = [&]<typename MappingFn>( MappingFn
>>> mappingFn )
>>>                  requires requires( MappingFn mappingFn, size_t i )
>>>                  {
>>>                      { mappingFn( i ) } -> same_as<size_t>;
>>>                  }
>>>              {
>>>                  for( unsigned nThreads = 1; nThreads <= toThread;
>>> ++nThreads )
>>>                  {
>>>                      vector<link_t *> &starts = chainStarts[nThreads -
>>> 1];
>>>                      double gap = (double)(ptrdiff_t)n / (int)nThreads;
>>>                      for( unsigned t = 0; t != nThreads; ++t )
>>>                          starts[t] = &links[mappingFn(
>>> (ptrdiff_t)((int)t * gap) )];
>>>                  }
>>>              };
>>>              if constexpr( Type == CmdLineParams::LINEAR || Type ==
>>> CmdLineParams::XLINEAR )
>>>              {
>>>                  auto linearConcat = [&]<typename MappingFn>(
>>> MappingFn mappingFn )
>>>                      requires requires( MappingFn mappingFn, size_t i )
>>>                      {
>>>                          { mappingFn( i ) } -> same_as<size_t>;
>>>                      }
>>>                  {
>>>                      for( size_t i = 0; i != n; ++i )
>>>                          links[i].next = &links[mappingFn( mappingFn(
>>> i ) + 1 & idxMask)];
>>>                  };
>>>                  if constexpr( Type == CmdLineParams::LINEAR )
>>>                  {
>>>                      auto directMap = []( size_t i ) { return i; };
>>>                      linearConcat( directMap );
>>>                      updateStarts( directMap );
>>>                  }
>>>                  else
>>>                  {
>>>                      size_t inverter = (size_t)0x5555555555555555u &
>>> idxMask;
>>>                      auto invertedMap = [&]( size_t i ) { return i ^
>>> inverter; };
>>>                      linearConcat( invertedMap );
>>>                      updateStarts( invertedMap );
>>>                  }
>>>                  return;
>>>              }
>>>              unsigned l2ThrTlbBits = l2TlbBits -
>>> (unsigned)(smtThreaded && l2TlbBits),
>>>                       l1ThrTlbBits = l1TlbBits -
>>> (unsigned)(smtThreaded && l1TlbBits);
>>>              unsigned l1Bits, l2Bits, outerBits;
>>>              size_t l2Mask, outerMask;
>>>              auto maskFromBits = []( unsigned bits ) -> size_t {
>>> return ((size_t)1 << bits) - 1; };
>>>              if constexpr( Type == CmdLineParams::TLB_RANDOM )
>>>                  if( bits > l2ThrTlbBits + pageBits )
>>>                      outerBits = bits - (l2ThrTlbBits + pageBits),
>>>                      outerMask = maskFromBits( outerBits ),
>>>                      l2Bits = l2ThrTlbBits - l1ThrTlbBits,
>>>                      l2Mask = maskFromBits( l2Bits ),
>>>                      l1Bits = l1ThrTlbBits + pageBits - linkBits;
>>>                  else if( bits > l1ThrTlbBits + pageBits )
>>>                      outerBits = 0,
>>>                      outerMask = 0,
>>>                      l2Bits = bits - (l1ThrTlbBits + pageBits),
>>>                      l2Mask = maskFromBits( l2Bits ),
>>>                      l1Bits = l1ThrTlbBits + pageBits - linkBits;
>>>                  else
>>>                      outerBits = 0,
>>>                      outerMask = 0,
>>>                      l2Bits = 0,
>>>                      l2Mask = 0,
>>>                      l1Bits = bits - linkBits;
>>>              else
>>>                  l1Bits = bits - linkBits;
>>>              auto flipIndex = [&]( size_t i ) -> size_t
>>>              {
>>>                  static unsigned const SZT_BITS = sizeof(size_t) *
>>> CHAR_BIT;
>>>                  size_t rL1 = reverseBits( i ) >> SZT_BITS - l1Bits;
>>>                  if constexpr( Type != CmdLineParams::TLB_RANDOM )
>>>                      return rL1;
>>>                  size_t rL2 = reverseBits( i >> l1Bits ) >> SZT_BITS -
>>> l2Bits & l2Mask,
>>>                         rOuter = reverseBits( i >> l2Bits + l1Bits )
>>> >> SZT_BITS - outerBits & outerMask;
>>>                  return rL1 + (rL2 << l1Bits) + (rOuter << l2Bits +
>>> l1Bits);
>>>              };
>>>              for( size_t rI = 0; rI != n; ++rI )
>>>                  links[rI].next = &links[flipIndex( flipIndex( rI ) +
>>> 1 & idxMask )];
>>>              updateStarts( flipIndex );
>>>          };
>>>
>>> Without lambdas and even more templated lambdas the code
>>> would become very complicated.
>>
>> Now that I know which bits are lambdas, and now that I know that you
>> mainly use lambdas to implement local functions, a missing C++ feature,
>> this code isn't really that remarkable.
>
>Lambdas are local functions and make the code _much_ more
>readable if you use them properly - like in the above example.

The above code is completely unreadable. And it was unreadable
even before being mangled by various NNTP clients.

Am 17.12.2021 um 17:25 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 17.12.2021 um 11:59 schrieb Bart:
>>
>>>> That's an example of my lambda-style:
>>>>
>>>>          auto buildChain = [&]<CmdLineParams::type_t Type>( bool
>>>> smtThreaded, unsigned toThread )
>>>>          {
>>>>              auto updateStarts = [&]<typename MappingFn>( MappingFn
>>>> mappingFn )
>>>>                  requires requires( MappingFn mappingFn, size_t i )
>>>>                  {
>>>>                      { mappingFn( i ) } -> same_as<size_t>;
>>>>                  }
>>>>              {
>>>>                  for( unsigned nThreads = 1; nThreads <= toThread;
>>>> ++nThreads )
>>>>                  {
>>>>                      vector<link_t *> &starts = chainStarts[nThreads -
>>>> 1];
>>>>                      double gap = (double)(ptrdiff_t)n / (int)nThreads;
>>>>                      for( unsigned t = 0; t != nThreads; ++t )
>>>>                          starts[t] = &links[mappingFn(
>>>> (ptrdiff_t)((int)t * gap) )];
>>>>                  }
>>>>              };
>>>>              if constexpr( Type == CmdLineParams::LINEAR || Type ==
>>>> CmdLineParams::XLINEAR )
>>>>              {
>>>>                  auto linearConcat = [&]<typename MappingFn>(
>>>> MappingFn mappingFn )
>>>>                      requires requires( MappingFn mappingFn, size_t i )
>>>>                      {
>>>>                          { mappingFn( i ) } -> same_as<size_t>;
>>>>                      }
>>>>                  {
>>>>                      for( size_t i = 0; i != n; ++i )
>>>>                          links[i].next = &links[mappingFn( mappingFn(
>>>> i ) + 1 & idxMask)];
>>>>                  };
>>>>                  if constexpr( Type == CmdLineParams::LINEAR )
>>>>                  {
>>>>                      auto directMap = []( size_t i ) { return i; };
>>>>                      linearConcat( directMap );
>>>>                      updateStarts( directMap );
>>>>                  }
>>>>                  else
>>>>                  {
>>>>                      size_t inverter = (size_t)0x5555555555555555u &
>>>> idxMask;
>>>>                      auto invertedMap = [&]( size_t i ) { return i ^
>>>> inverter; };
>>>>                      linearConcat( invertedMap );
>>>>                      updateStarts( invertedMap );
>>>>                  }
>>>>                  return;
>>>>              }
>>>>              unsigned l2ThrTlbBits = l2TlbBits -
>>>> (unsigned)(smtThreaded && l2TlbBits),
>>>>                       l1ThrTlbBits = l1TlbBits -
>>>> (unsigned)(smtThreaded && l1TlbBits);
>>>>              unsigned l1Bits, l2Bits, outerBits;
>>>>              size_t l2Mask, outerMask;
>>>>              auto maskFromBits = []( unsigned bits ) -> size_t {
>>>> return ((size_t)1 << bits) - 1; };
>>>>              if constexpr( Type == CmdLineParams::TLB_RANDOM )
>>>>                  if( bits > l2ThrTlbBits + pageBits )
>>>>                      outerBits = bits - (l2ThrTlbBits + pageBits),
>>>>                      outerMask = maskFromBits( outerBits ),
>>>>                      l2Bits = l2ThrTlbBits - l1ThrTlbBits,
>>>>                      l2Mask = maskFromBits( l2Bits ),
>>>>                      l1Bits = l1ThrTlbBits + pageBits - linkBits;
>>>>                  else if( bits > l1ThrTlbBits + pageBits )
>>>>                      outerBits = 0,
>>>>                      outerMask = 0,
>>>>                      l2Bits = bits - (l1ThrTlbBits + pageBits),
>>>>                      l2Mask = maskFromBits( l2Bits ),
>>>>                      l1Bits = l1ThrTlbBits + pageBits - linkBits;
>>>>                  else
>>>>                      outerBits = 0,
>>>>                      outerMask = 0,
>>>>                      l2Bits = 0,
>>>>                      l2Mask = 0,
>>>>                      l1Bits = bits - linkBits;
>>>>              else
>>>>                  l1Bits = bits - linkBits;
>>>>              auto flipIndex = [&]( size_t i ) -> size_t
>>>>              {
>>>>                  static unsigned const SZT_BITS = sizeof(size_t) *
>>>> CHAR_BIT;
>>>>                  size_t rL1 = reverseBits( i ) >> SZT_BITS - l1Bits;
>>>>                  if constexpr( Type != CmdLineParams::TLB_RANDOM )
>>>>                      return rL1;
>>>>                  size_t rL2 = reverseBits( i >> l1Bits ) >> SZT_BITS -
>>>> l2Bits & l2Mask,
>>>>                         rOuter = reverseBits( i >> l2Bits + l1Bits )
>>>>>> SZT_BITS - outerBits & outerMask;
>>>>                  return rL1 + (rL2 << l1Bits) + (rOuter << l2Bits +
>>>> l1Bits);
>>>>              };
>>>>              for( size_t rI = 0; rI != n; ++rI )
>>>>                  links[rI].next = &links[flipIndex( flipIndex( rI ) +
>>>> 1 & idxMask )];
>>>>              updateStarts( flipIndex );
>>>>          };
>>>>
>>>> Without lambdas and even more templated lambdas the code
>>>> would become very complicated.
>>>
>>> Now that I know which bits are lambdas, and now that I know that you
>>> mainly use lambdas to implement local functions, a missing C++ feature,
>>> this code isn't really that remarkable.
>>
>> Lambdas are local functions and make the code _much_ more
>> readable if you use them properly - like in the above example.
>
> The above code is completely unreadable. And it was unreadable
> even before being mangled by various NNTP clients.

The code is unreadable because you don't know what it's good for.

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.

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.

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.

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.

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.

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.

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

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

> because these make code more elegant without adding any weird
> garbage or confusion.

Lambdas are not confusing. But variadic templates can be very confusing.