Am 13.10.2023 um 18:34 schrieb Kaz Kylheku:

> I don't believe it. ...

Compile it with Godbolt and you see that the lambda is instantiated
twice.

> It's possible that inlining will render this consideration
> moot, because if the function is inlined, then no actual calls are
> happening, and there are no calling conventions.

The function is called behind a volatile function pointer, so there's
no inlining.

Rest of your nonsense unread.

On 10/14/23 9:52 AM, Bonita Montero wrote:
> Am 13.10.2023 um 18:12 schrieb Richard Damon:
>> On 10/11/23 1:22 PM, Bonita Montero wrote:
>>> Am 11.10.2023 um 15:12 schrieb Kenny McCormack:
>>>
>>>> Actually, it is pretty easy to answer OP's question.  Here's what it
>>>> prints:
>>>>
>>>> <stdin>: In function 'int main()':
>>>> <stdin>:12:8: error: '__fastcall' was not declared in this scope
>>>> <stdin>:12:3: error: expected primary-expression before 'int'
>>>> <stdin>:13:8: error: '__stdcall' was not declared in this scope
>>>> <stdin>:13:3: error: expected primary-expression before 'int'
>>>> <stdin>:14:11: error: 'pFnFastcall' was not declared in this scope
>>>> <stdin>:15:11: error: 'pFnStdcall' was not declared in this scope
>>>>
>>>> And it is, in theory at least, possible to predict that without using a
>>>> compiler (though, truth to be told, I did cheat and use the compiler).
>>>
>>> Use a compiler which knows __fastcall and __stdcall.
>>>
>>>
>>
>> But ANY program using those, that is to be interpreted as "Standard
>> C++", has, by the Standard "Undefined Behavior".
>
> This is just a Windows program. If you don't like it, don't worry
> about  it.Others might be able to understand this without Windows,
> but you can't.
>
>

Who said I didn't understand it.

YOU are the one that doesn't seem to understand what a Standard says.

YOU didn't say "Windows", so YOU are the one that made the error,
perhaps because you think all the world is just Windows, which is WRONG
(and shows your ignorance).

>
>>
>> So, the answer, when posted as a general "C++" question, is, it does
>> what ever the implementation wants it to do.
>>
>> To get your answer, you need to limit the "Language" of the program to
>> the particular implementation you desire.
>>
>> I could CORRECTLY state (if I want to go to the effort) that when I
>> complied the program, its output was "Bonita is a idiot", because that
>> is what the Damon C++ compiler generated, and it is fully conforming.
>>
>> (And that answer IS a correct statement).
>

On 10/14/23 9:53 AM, Bonita Montero wrote:
> Am 13.10.2023 um 18:15 schrieb Richard Damon:
>> On 10/13/23 2:50 AM, Bonita Montero wrote:
>>> Am 13.10.2023 um 05:50 schrieb Chris M. Thomasson:
>>>> On 10/11/2023 6:03 AM, Ben Bacarisse wrote:
>>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>>
>>>>>> #include <iostream>
>>>>>>
>>>>>> using namespace std;
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>     auto lambda = []( int a ) -> int
>>>>>>     {
>>>>>>         thread_local int i = 0;
>>>>>>         return i++ + a;
>>>>>>     };
>>>>>>     int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>>>>>>     int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>>>>>>     cout << pFnFastcall( 10 ) << endl;
>>>>>>     cout << pFnStdcall( 9 ) << endl;
>>>>>> }
>>>>>>
>>>>>> Don't compile it yourself,
>>>>>
>>>>> An easy injunction to follow since it has syntax errors!  Presumably
>>>>> those undeclared identifiers (or proprietary keywords?) have some
>>>>> meaning to your compiler.
>>>>>
>>>>>> just guess.
>>>>>
>>>>
>>>>
>>>> What is 10 * 10?
>>>> It's one hundred percent that the lovely Bonita is a troll.
>>>
>>>
>>> O.k., I'll explain it: the lambda is compiled twice for each cal-
>>> ling convention but in contrast to a generic lambda the thread
>>> local variable "i" exists only once for both "instantiations" !
>>> With a generic lambda there would be an "i" for each instanti-
>>> ation of the lambda's calling operator. I thought the people
>>> here should be able to think about that without compiling the
>>> code.
>>> And you call that trolling ...
>>
>> And your lack of knowledge of how the standard actually works just
>> shows how little you really know.
>
> I know that this isn't standard C++.
> But this doesn't matter for my question.

IF you don't have a "Standard" to apply the question to ANY answer could
be correct.

As I said, YOU can't refute that under a possible implementation, the
correct answer would be:

"Bonita is an Idiot" (or anything else).

So, you are just asking meaningless questions.

On 10/13/23 2:50 AM, Bonita Montero wrote:
> Am 13.10.2023 um 05:50 schrieb Chris M. Thomasson:
>> On 10/11/2023 6:03 AM, Ben Bacarisse wrote:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>
>>>> #include <iostream>
>>>>
>>>> using namespace std;
>>>>
>>>> int main()
>>>> {
>>>>     auto lambda = []( int a ) -> int
>>>>     {
>>>>         thread_local int i = 0;
>>>>         return i++ + a;
>>>>     };
>>>>     int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>>>>     int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>>>>     cout << pFnFastcall( 10 ) << endl;
>>>>     cout << pFnStdcall( 9 ) << endl;
>>>> }
>>>>
>>>> Don't compile it yourself,
>>>
>>> An easy injunction to follow since it has syntax errors!  Presumably
>>> those undeclared identifiers (or proprietary keywords?) have some
>>> meaning to your compiler.
>>>
>>>> just guess.
>>>
>>
>>
>> What is 10 * 10?
>> It's one hundred percent that the lovely Bonita is a troll.
>
>
> O.k., I'll explain it: the lambda is compiled twice for each cal-
> ling convention but in contrast to a generic lambda the thread
> local variable "i" exists only once for both "instantiations" !
> With a generic lambda there would be an "i" for each instanti-
> ation of the lambda's calling operator. I thought the people
> here should be able to think about that without compiling the
> code.
> And you call that trolling ...

Can you point to any words in the standard that allows the lambda
expression to get "recompiled" for different calling conventions?

Since the lambda has no "auto" parameters, it is NOT a "generic" lambda
that gets recompiled under different usages, so I am not sure what basis
you have to claim the ability to "compile" it generically.

This might just be a common extension.

The fact that others have pointed out that when compiling for current
operating systems, the common compilers that understand those reserved
symbols point out that they are just ignored.

Did you actually look at the generated code to see that it in fact DID
get generated twice? or are you just guessing (perhaps wrongly) as you
seem to do so often.

On 2023-10-14, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> Am 13.10.2023 um 18:34 schrieb Kaz Kylheku:
>
>> I don't believe it. ...
>
> Compile it with Godbolt and you see that the lambda is instantiated
> twice.

To clarify, what I don't believe is the idea that the behavior you are
seeing is documented and reliable.

>> It's possible that inlining will render this consideration
>> moot, because if the function is inlined, then no actual calls are
>> happening, and there are no calling conventions.
>
> The function is called behind a volatile function pointer, so there's
> no inlining.

A volatile on a local variable whose address isn't taken, in a function
where setjmp isn't being used, means approximately to nothing. The
compiler is allowed to deduce that the pointer points to that lambda
regardless of the volatile.

> Rest of your nonsense unread.

"Nonsense" like how different calling conventions are incompatible,
making the code utter garbage where those keywords are not ignored.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 10/12/2023 11:50 PM, Bonita Montero wrote:
> Am 13.10.2023 um 05:50 schrieb Chris M. Thomasson:
>> On 10/11/2023 6:03 AM, Ben Bacarisse wrote:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>
>>>> #include <iostream>
>>>>
>>>> using namespace std;
>>>>
>>>> int main()
>>>> {
>>>>     auto lambda = []( int a ) -> int
>>>>     {
>>>>         thread_local int i = 0;
>>>>         return i++ + a;
>>>>     };
>>>>     int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>>>>     int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>>>>     cout << pFnFastcall( 10 ) << endl;
>>>>     cout << pFnStdcall( 9 ) << endl;
>>>> }
>>>>
>>>> Don't compile it yourself,
>>>
>>> An easy injunction to follow since it has syntax errors!  Presumably
>>> those undeclared identifiers (or proprietary keywords?) have some
>>> meaning to your compiler.
>>>
>>>> just guess.
>>>
>>
>>
>> What is 10 * 10?
>> It's one hundred percent that the lovely Bonita is a troll.
>
>
> O.k., I'll explain it: the lambda is compiled twice for each cal-
> ling convention but in contrast to a generic lambda the thread
> local variable "i" exists only once for both "instantiations" !
> With a generic lambda there would be an "i" for each instanti-
> ation of the lambda's calling operator. I thought the people
> here should be able to think about that without compiling the
> code.
> And you call that trolling ...

10 10 is a hint...

14.10.2023 21:33 Chris M. Thomasson kirjutas:
> On 10/12/2023 11:50 PM, Bonita Montero wrote:
>> Am 13.10.2023 um 05:50 schrieb Chris M. Thomasson:
>>> On 10/11/2023 6:03 AM, Ben Bacarisse wrote:
>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>
>>>>> #include <iostream>
>>>>>
>>>>> using namespace std;
>>>>>
>>>>> int main()
>>>>> {
>>>>>     auto lambda = []( int a ) -> int
>>>>>     {
>>>>>         thread_local int i = 0;
>>>>>         return i++ + a;
>>>>>     };
>>>>>     int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>>>>>     int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>>>>>     cout << pFnFastcall( 10 ) << endl;
>>>>>     cout << pFnStdcall( 9 ) << endl;
>>>>> }
>
> 10 10 is a hint...

I also got 10 10, first in my head, and my compiler agreed as well (VS2022).

On 10/14/2023 11:54 AM, Paavo Helde wrote:
> 14.10.2023 21:33 Chris M. Thomasson kirjutas:
>> On 10/12/2023 11:50 PM, Bonita Montero wrote:
>>> Am 13.10.2023 um 05:50 schrieb Chris M. Thomasson:
>>>> On 10/11/2023 6:03 AM, Ben Bacarisse wrote:
>>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>>
>>>>>> #include <iostream>
>>>>>>
>>>>>> using namespace std;
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>     auto lambda = []( int a ) -> int
>>>>>>     {
>>>>>>         thread_local int i = 0;
>>>>>>         return i++ + a;
>>>>>>     };
>>>>>>     int (__fastcall *volatile pFnFastcall)( int ) = lambda;
>>>>>>     int (__stdcall *volatile pFnStdcall)( int ) = lambda;
>>>>>>     cout << pFnFastcall( 10 ) << endl;
>>>>>>     cout << pFnStdcall( 9 ) << endl;
>>>>>> }
>>
>> 10 10 is a hint...
>
> I also got 10 10, first in my head, and my compiler agreed as well
> (VS2022).

:^)

I wanted to see if Bonita would pick on my message up thread that says:
_________________
What is 10 * 10? It's one hundred percent that the lovely Bonita is a
troll.
_________________

Just wanted to see if he/she could pick up on it.

On 10/14/23 2:05 PM, Kaz Kylheku wrote:
> On 2023-10-14, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 13.10.2023 um 18:34 schrieb Kaz Kylheku:
>>
>>> I don't believe it. ...
>>
>> Compile it with Godbolt and you see that the lambda is instantiated
>> twice.
>
> To clarify, what I don't believe is the idea that the behavior you are
> seeing is documented and reliable.
>
>>> It's possible that inlining will render this consideration
>>> moot, because if the function is inlined, then no actual calls are
>>> happening, and there are no calling conventions.
>>
>> The function is called behind a volatile function pointer, so there's
>> no inlining.
>
> A volatile on a local variable whose address isn't taken, in a function
> where setjmp isn't being used, means approximately to nothing. The
> compiler is allowed to deduce that the pointer points to that lambda
> regardless of the volatile.

I don't think that is true, The volatile modifier says that it might be
changed/accessed by things beyond the implementations knowledge. The
caller might well have passed the address of the future variable to
some other actor, perhaps getting an interrupt when the variable was
written and then doing something to it.

>
>> Rest of your nonsense unread.
>
> "Nonsense" like how different calling conventions are incompatible,
> making the code utter garbage where those keywords are not ignored.
>

Am 14.10.2023 um 20:05 schrieb Kaz Kylheku:

> To clarify, what I don't believe is the idea that the behavior you are
> seeing is documented and reliable.

If MSVC supports that it won't drop that. clang-cl also supports
that for a long time, but implemented that later than MSVC.

> A volatile on a local variable whose address isn't taken, in a function
> where setjmp isn't being used, means approximately to nothing.

What a volatile does is compiler-dependent and both supporting compilers
(MSVC, clang-cl) implemented that in a way that what I did works, i.e.
the compiler couldn't inline the code.

Am 14.10.2023 um 17:26 schrieb Richard Damon:

> "Bonita is an Idiot" (or anything else).

No, you were just frustated that you didn't know the answer
to my initial question and wanted to discuss away the question
with: this isn't up to the standard.

Am 14.10.2023 um 18:47 schrieb Richard Damon:

> Can you point to any words in the standard that allows the lambda
> expression to get "recompiled" for different calling conventions?

MSVC and clang-cl do that.

> Since the lambda has no "auto" parameters, it is NOT a "generic" lambda
> that gets recompiled under different usages, ...

I didn't say that it is generic but there's an opposite analogy to
generic lambdas that thread local and shared variables are shared
among the different instantiations for different calling conventions.

> The fact that others have pointed out that when compiling for current
> operating systems, the common compilers that understand those reserved
> symbols point out that they are just ignored.

The compiler can't ignore the calling convention since the definition
of the variable and the assignment might be spareate. I just printed
both pointer's addresses and I get different addresses. So there are
only two options left: either there are separate instantiations for
each calling convention or there's additional thunk code for each
calling convention that doesn't mach the standard calling convention.

> Did you actually look at the generated code to see that it in fact DID
> get generated twice? ...

Yes, and as I said both pointers have different addresses.

Am 14.10.2023 um 17:26 schrieb Richard Damon:

> Who said I didn't understand it.

You're a nerd and I know nerds.

Am 15.10.2023 um 09:07 schrieb Bonita Montero:

> The compiler can't ignore the calling convention since the definition
> of the variable and the assignment might be spareate. I just printed
> both pointer's addresses and I get different addresses. So there are
> only two options left: either there are separate instantiations for
> each calling convention or there's additional thunk code for each
> calling convention that doesn't mach the standard calling convention.

This are both instantiations copied from the disassembly in the
debugger:

005F10D0 64 A1 2C 00 00 00 mov eax,dword ptr fs:[0000002Ch]
005F10D6 56 push esi
005F10D7 8B 30 mov esi,dword ptr [eax]
005F10D9 8B 96 04 00 00 00 mov edx,dword ptr [esi+4]
005F10DF 8D 42 01 lea eax,[edx+1]
005F10E2 89 86 04 00 00 00 mov dword ptr [esi+4],eax
005F10E8 8D 04 0A lea eax,[edx+ecx]
005F10EB 5E pop esi
005F10EC C3 ret

005F10A0 55 push ebp
005F10A1 8B EC mov ebp,esp
005F10A3 64 A1 2C 00 00 00 mov eax,dword ptr fs:[0000002Ch]
005F10A9 8B 08 mov ecx,dword ptr [eax]
005F10AB 8B 91 04 00 00 00 mov edx,dword ptr [ecx+4]
005F10B1 8D 42 01 lea eax,[edx+1]
005F10B4 89 81 04 00 00 00 mov dword ptr [ecx+4],eax
005F10BA 8B 45 08 mov eax,dword ptr [a]
005F10BD 03 C2 add eax,edx
005F10BF 5D pop ebp
005F10C0 C2 04 00 ret 4

Am 15.10.2023 um 09:12 schrieb Bonita Montero:
> Am 15.10.2023 um 09:07 schrieb Bonita Montero:
>
>> The compiler can't ignore the calling convention since the definition
>> of the variable and the assignment might be spareate. I just printed
>> both pointer's addresses and I get different addresses. So there are
>> only two options left: either there are separate instantiations for
>> each calling convention or there's additional thunk code for each
>> calling convention that doesn't mach the standard calling convention.
>
> This are both instantiations copied from the disassembly in the
> debugger:
>
> 005F10D0 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]
> 005F10D6 56                   push        esi
> 005F10D7 8B 30                mov         esi,dword ptr [eax]
> 005F10D9 8B 96 04 00 00 00    mov         edx,dword ptr [esi+4]
> 005F10DF 8D 42 01             lea         eax,[edx+1]
> 005F10E2 89 86 04 00 00 00    mov         dword ptr [esi+4],eax
> 005F10E8 8D 04 0A             lea         eax,[edx+ecx]
> 005F10EB 5E                   pop         esi
> 005F10EC C3                   ret
>
> 005F10A0 55                   push        ebp
> 005F10A1 8B EC                mov         ebp,esp
> 005F10A3 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]
> 005F10A9 8B 08                mov         ecx,dword ptr [eax]
> 005F10AB 8B 91 04 00 00 00    mov         edx,dword ptr [ecx+4]
> 005F10B1 8D 42 01             lea         eax,[edx+1]
> 005F10B4 89 81 04 00 00 00    mov         dword ptr [ecx+4],eax
> 005F10BA 8B 45 08             mov         eax,dword ptr [a]
> 005F10BD 03 C2                add         eax,edx
> 005F10BF 5D                   pop         ebp
> 005F10C0 C2 04 00             ret         4

The symbols for both functions are ...

* `main'::`2'::<lambda_1>::<lambda_invoker_fastcall>
* `main'::`2'::<lambda_1>::<lambda_invoker_stdcall>

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 14.10.2023 um 18:47 schrieb Richard Damon:
>
>> Can you point to any words in the standard that allows the lambda
>> expression to get "recompiled" for different calling conventions?
>
>MSVC and clang-cl do that.

So, you cannot point to any words in the standard. Noted.

Really who cares about fast call and standard call? They're
completely ignored on all modern 64-bit processors.

Am 15.10.2023 um 16:36 schrieb Scott Lurndal:

> So, you cannot point to any words in the standard. Noted.

If you don't like platform-specific objections don't read them.

On 10/15/23 3:00 AM, Bonita Montero wrote:
> Am 14.10.2023 um 17:26 schrieb Richard Damon:
>
>> "Bonita is an Idiot" (or anything else).
>
> No, you were just frustated that you didn't know the answer
> to my initial question and wanted to discuss away the question
> with: this isn't up to the standard.

What make you say that?

Note, your initial question was malformed, as the program given was
malformed except for systems that understood a given extension to the
standard, that was not specified.

The answer that you get possible syntax error when compiled, which was
an answer given WAS the correct answer.

And, what is wrong with my answer? Since you didn't specify that your
program required a certain extension implemented in a certain way, my
implementation is just as valie.

And you are showing the limitations in your understand of the language.

On 10/15/23 3:07 AM, Bonita Montero wrote:
> Am 14.10.2023 um 18:47 schrieb Richard Damon:
>
>> Can you point to any words in the standard that allows the lambda
>> expression to get "recompiled" for different calling conventions?
>
> MSVC and clang-cl do that.

So, the answer is no. You are relying on an extension to the Standard,
that you didn't require. One that perhaps by the Standard, should
require a diagnostic to be conforming.

>
>> Since the lambda has no "auto" parameters, it is NOT a "generic"
>> lambda that gets recompiled under different usages, ...
>
> I didn't say that it is generic but there's an opposite analogy to
> generic lambdas that thread local and shared variables are shared
> among the different instantiations for different calling conventions.

Right, but you created "two lambdas" by using something that violates
the standard. Note "Calling Convention" isn't listed as something you
are defined to be able to overload on, so there can't actually be two
lambda functions with the same name that differ by just calling convention.

>
>> The fact that others have pointed out that when compiling for current
>> operating systems, the common compilers that understand those reserved
>> symbols point out that they are just ignored.
>
> The compiler can't ignore the calling convention since the definition
> of the variable and the assignment might be spareate. I just printed
> both pointer's addresses and I get different addresses. So there are
> only two options left: either there are separate instantiations for
> each calling convention or there's additional thunk code for each
> calling convention that doesn't mach the standard calling convention.

Even by the normal interpreation of the Standard with this extension, I
belive the lambda will be generated with the default calling convention.
The complier might then generate thunks to handle the differing
conventions. I would need to setup an environment to check this, which
isn't worth my effort.

>
>> Did you actually look at the generated code to see that it in fact DID
>> get generated twice? ...
>
> Yes, and as I said both pointers have different addresses.
>

So, you don't know what it means to look at generated code.

Just proves your limitation in knowledge of the subject.

Note, I admit when I am going on presumption and not fact, you don't
seem to know the difference. Probably because you don't understand what
is actually fact or required.

On 10/15/23 3:16 AM, Bonita Montero wrote:
> Am 15.10.2023 um 09:12 schrieb Bonita Montero:
>> Am 15.10.2023 um 09:07 schrieb Bonita Montero:
>>
>>> The compiler can't ignore the calling convention since the definition
>>> of the variable and the assignment might be spareate. I just printed
>>> both pointer's addresses and I get different addresses. So there are
>>> only two options left: either there are separate instantiations for
>>> each calling convention or there's additional thunk code for each
>>> calling convention that doesn't mach the standard calling convention.
>>
>> This are both instantiations copied from the disassembly in the
>> debugger:
>>
>> 005F10D0 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]
>> 005F10D6 56                   push        esi
>> 005F10D7 8B 30                mov         esi,dword ptr [eax]
>> 005F10D9 8B 96 04 00 00 00    mov         edx,dword ptr [esi+4]
>> 005F10DF 8D 42 01             lea         eax,[edx+1]
>> 005F10E2 89 86 04 00 00 00    mov         dword ptr [esi+4],eax
>> 005F10E8 8D 04 0A             lea         eax,[edx+ecx]
>> 005F10EB 5E                   pop         esi
>> 005F10EC C3                   ret
>>
>> 005F10A0 55                   push        ebp
>> 005F10A1 8B EC                mov         ebp,esp
>> 005F10A3 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]
>> 005F10A9 8B 08                mov         ecx,dword ptr [eax]
>> 005F10AB 8B 91 04 00 00 00    mov         edx,dword ptr [ecx+4]
>> 005F10B1 8D 42 01             lea         eax,[edx+1]
>> 005F10B4 89 81 04 00 00 00    mov         dword ptr [ecx+4],eax
>> 005F10BA 8B 45 08             mov         eax,dword ptr [a]
>> 005F10BD 03 C2                add         eax,edx
>> 005F10BF 5D                   pop         ebp
>> 005F10C0 C2 04 00             ret         4
>
> The symbols for both functions are ...
>
> * `main'::`2'::<lambda_1>::<lambda_invoker_fastcall>
> * `main'::`2'::<lambda_1>::<lambda_invoker_stdcall>
>

So, two wrappers for the same function. just different instances of the
invoking of it, not two different "instances" of the lambda function.

On 10/15/23 3:12 AM, Bonita Montero wrote:
> Am 15.10.2023 um 09:07 schrieb Bonita Montero:
>
>> The compiler can't ignore the calling convention since the definition
>> of the variable and the assignment might be spareate. I just printed
>> both pointer's addresses and I get different addresses. So there are
>> only two options left: either there are separate instantiations for
>> each calling convention or there's additional thunk code for each
>> calling convention that doesn't mach the standard calling convention.
>
> This are both instantiations copied from the disassembly in the
> debugger:
>
> 005F10D0 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]
> 005F10D6 56                   push        esi
> 005F10D7 8B 30                mov         esi,dword ptr [eax]
> 005F10D9 8B 96 04 00 00 00    mov         edx,dword ptr [esi+4]
> 005F10DF 8D 42 01             lea         eax,[edx+1]
> 005F10E2 89 86 04 00 00 00    mov         dword ptr [esi+4],eax
> 005F10E8 8D 04 0A             lea         eax,[edx+ecx]
> 005F10EB 5E                   pop         esi
> 005F10EC C3                   ret
>
> 005F10A0 55                   push        ebp
> 005F10A1 8B EC                mov         ebp,esp
> 005F10A3 64 A1 2C 00 00 00    mov         eax,dword ptr fs:[0000002Ch]
> 005F10A9 8B 08                mov         ecx,dword ptr [eax]
> 005F10AB 8B 91 04 00 00 00    mov         edx,dword ptr [ecx+4]
> 005F10B1 8D 42 01             lea         eax,[edx+1]
> 005F10B4 89 81 04 00 00 00    mov         dword ptr [ecx+4],eax
> 005F10BA 8B 45 08             mov         eax,dword ptr [a]
> 005F10BD 03 C2                add         eax,edx
> 005F10BF 5D                   pop         ebp
> 005F10C0 C2 04 00             ret         4
>
>

Which is also consistant with a single definition that was inline
expanded at the two assignment sites

Thus it isn't that you got "two different lambda" with different calling
convention refencing the same variable, but you have ONE lambda, that is
inlined twice with different wrappers to handle calling convention, that
since it is the same function being called, of course share the common
variable (as is required anytime an inline function is used).

On 10/15/2023 12:08 AM, Bonita Montero wrote:
> Am 14.10.2023 um 17:26 schrieb Richard Damon:
>
>> Who said I didn't understand it.
>
> You're a nerd and I know nerds.

Huh? That is a very odd thing to say even for a naive troll. Okay Bonita
The Beautiful Woman. Are you like the cruel puppet for real? The only
way to defend yourself is with mental straining. Are you the real one?

https://www.thezorklibrary.com/history/cruel_puppet.html

___________________
Few creatures are more despised than the cruel puppet, one which uses
its power not for good, evil or profit, but simply to hurt people's
feelings. Staunch monarchs have been reduced to tears by these merciless
shapeshifters; for it attacks by twisting itself into unflattering
caricatures of its opponents, accompanied by jeers, rude noises and
shocking accusations--which include the recital of nightly personal
habits in excruciating detail, accusing its adversary's mother of
shocking improprieties, reminding of weight gain, etc. They have also
been known to practice existential put downs. "You're so ugly you're
probably the creation of an unseen master who is controlling and shaping
the world around you. Nothing is real and nothing you do will have any
lasting effect on those around you. Welcome to the dark night of your
soul" is but one example. More often, however, they just insult your
knees. Insulting the cruel puppet in return is futile, for it feeds off
of them. Straining to ignore these verbal attacks is the only known defense.

Residents of Gurth City were warned during the mid-tenth century to keep
away from the Forest of Youth, as it was known home to cruel puppets.

During the Great Monster Uprising of the Second Age of Magic, cruel
puppets were reported in the following regions: The abandoned Casino of
Port Foozle, The Southern Wastes, The Coast Road near Borphee, Pheebor,
Forest of Youth, Gurth Woodland Trail, the Lost Castle of Y'Syska, Crab
Island, Egreth Castle, The Glass Maze, Bozbarland, Largoneth Castle, and
the G.U.E. Tech Training Grounds in the Ethereal Plane of Atrii. Many
perched in trees and other high and covert corners, raining handfuls of
exploding chestnuts down upon luckless adventurers.
___________________

On 10/15/23 3:08 AM, Bonita Montero wrote:
> Am 14.10.2023 um 17:26 schrieb Richard Damon:
>
>> Who said I didn't understand it.
>
> You're a nerd and I know nerds.

So, you are wrong, but can't admit it.

On 10/15/23 12:15 PM, Bonita Montero wrote:
> Am 15.10.2023 um 16:36 schrieb Scott Lurndal:
>
>> So, you cannot point to any words in the standard.  Noted.
>
> If you don't like platform-specific objections don't read them.
>
>
If making platform-specific question, mention the platform, or better,
post it in the platform specific group.

Platform specific code, when not restricted to the platform, is often
undefined in the more general world.

Am 15.10.2023 um 19:15 schrieb Richard Damon:

> What make you say that?

I know nerds.

Rest unread.