Am 25.10.2023 um 18:21 schrieb Richard Damon:

> The key point is that for functions that are inlined, each inlined
> "instance" of the function doesn't get new shared static/thread-local
> variables. This is REQUIRED as inlining isn't allowed to change the
> visible behavior of the function, but is just an optimization.

We don't discuss standard issues.

On 10/25/23 9:24 AM, Bonita Montero wrote:
> Am 25.10.2023 um 18:21 schrieb Richard Damon:
>
>> The key point is that for functions that are inlined, each inlined
>> "instance" of the function doesn't get new shared static/thread-local
>> variables. This is REQUIRED as inlining isn't allowed to change the
>> visible behavior of the function, but is just an optimization.
>
> We don't discuss standard issues.

Maybe you don't, but the topic space of this newsgroup is "standard" C++.

On 10/25/2023 9:01 AM, Bonita Montero wrote:
> Am 25.10.2023 um 17:43 schrieb Richard Damon:
>
>> After all, for a "generic" lambda, each variation is really a
>> different function (just like a template function), but each instance
>> of a GIVEN instance of the "generic" lambda, just like the non-generic
>> lambda, or even an ordinary function, when inlined MUST share static
>> or thread_local variables.
>
> I would also have thought it acceptable if each "instance" of
> the lambda had its own static and thread-local variables for
> each calling convention. In practice, it would be very atypical
> if you actually instantiate the lambda with several calling
> conventions.

Humm... This means you do not understand thread_local at all. Study up!
In this case it is working with the thread calling main. Your "fluff"
does not matter one bit.

On 10/25/2023 11:23 AM, Richard Damon wrote:
> On 10/25/23 9:24 AM, Bonita Montero wrote:
>> Am 25.10.2023 um 18:21 schrieb Richard Damon:
>>
>>> The key point is that for functions that are inlined, each inlined
>>> "instance" of the function doesn't get new shared static/thread-local
>>> variables. This is REQUIRED as inlining isn't allowed to change the
>>> visible behavior of the function, but is just an optimization.
>>
>> We don't discuss standard issues.
>
> Maybe you don't, but the topic space of this newsgroup is "standard" C++.

Bonita is radically confused here. Shit happens. ;^o

On 10/25/23 9:24 AM, Bonita Montero wrote:
....
> We don't discuss standard issues.

Correct, that's the domain of comp.std.c++. This group is for discussing
the language defined by that standard, nor for discussing the standard
itself.

Am 25.10.2023 um 20:23 schrieb Richard Damon:
> On 10/25/23 9:24 AM, Bonita Montero wrote:
>> Am 25.10.2023 um 18:21 schrieb Richard Damon:
>>
>>> The key point is that for functions that are inlined, each inlined
>>> "instance" of the function doesn't get new shared static/thread-local
>>> variables. This is REQUIRED as inlining isn't allowed to change the
>>> visible behavior of the function, but is just an optimization.
>>
>> We don't discuss standard issues.
>
> Maybe you don't, but the topic space of this newsgroup is "standard" C++.

I started a platform-specific topic and you continued to reason
why it is implemented as it is with standard-specific reasoning.

Am 26.10.2023 um 00:01 schrieb Chris M. Thomasson:

> Humm... This means you do not understand thread_local at all.

I wanted to say that it would be acceptable if MSVC would have
implemented as if the funtions would be separated, just as if
I'd have a generic calling operator.

On 10/25/23 10:13 PM, Bonita Montero wrote:
> Am 25.10.2023 um 20:23 schrieb Richard Damon:
>> On 10/25/23 9:24 AM, Bonita Montero wrote:
>>> Am 25.10.2023 um 18:21 schrieb Richard Damon:
>>>
>>>> The key point is that for functions that are inlined, each inlined
>>>> "instance" of the function doesn't get new shared
>>>> static/thread-local variables. This is REQUIRED as inlining isn't
>>>> allowed to change the visible behavior of the function, but is just
>>>> an optimization.
>>>
>>> We don't discuss standard issues.
>>
>> Maybe you don't, but the topic space of this newsgroup is "standard" C++.
>
> I started a platform-specific topic and you continued to reason
> why it is implemented as it is with standard-specific reasoning.

No, you started a topic asking what some code did in a newsgroup for
GENERAL C++ discussion that should have been done in a platform specific
group.

This was pointed out in the beginning.

THe Standard still applies to the question, as we are discussing parts
of the behavior that is actually specified by the standard, and the
platforms conform to those parts of the standard, even in there
extension that you were using,

You just don't understand how the Language works.

On 10/25/23 10:15 PM, Bonita Montero wrote:
> Am 26.10.2023 um 00:01 schrieb Chris M. Thomasson:
>
>> Humm... This means you do not understand thread_local at all.
>
> I wanted to say that it would be acceptable if MSVC would have
> implemented as if the funtions would be separated, just as if
> I'd have a generic calling operator.
>

Nope, it would have violated the standard.

a generic lambda can only overload its definitions on what a function is
allowed to be overloaded on.

This is only the types of the parameters.

Calling convention is NOT this, and is not eligable for overloading, in
part because you can not tell in general which of the overloads by
calling convention to use when you see the call, just as you can't
overload by return type.

It just isn't allowed.

PERIOD.

Thus MSVC would have been more non-conforming to support that behavior,
so they don't.

On 10/25/2023 3:02 PM, Chris M. Thomasson wrote:
> On 10/25/2023 11:23 AM, Richard Damon wrote:
>> On 10/25/23 9:24 AM, Bonita Montero wrote:
>>> Am 25.10.2023 um 18:21 schrieb Richard Damon:
>>>
>>>> The key point is that for functions that are inlined, each inlined
>>>> "instance" of the function doesn't get new shared
>>>> static/thread-local variables. This is REQUIRED as inlining isn't
>>>> allowed to change the visible behavior of the function, but is just
>>>> an optimization.
>>>
>>> We don't discuss standard issues.
>>
>> Maybe you don't, but the topic space of this newsgroup is "standard" C++.
>
> Bonita is radically confused here. Shit happens. ;^o

Sometimes I think Bonita rushes into things without engaging the good
ol' brain... Humm...

https://youtu.be/GU9RrgbzVYI