Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #92556 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2023-10-11 05:30 +0200 |
| Last post | 2023-10-25 23:12 -0700 |
| Articles | 20 on this page of 134 — 12 participants |
Back to article view | Back to comp.lang.c++
What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-11 05:30 +0200
Re: What does this code print ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-11 14:03 +0100
Re: What does this code print ? gazelle@shell.xmission.com (Kenny McCormack) - 2023-10-11 13:12 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-11 19:22 +0200
Re: What does this code print ? scott@slp53.sl.home (Scott Lurndal) - 2023-10-11 17:41 +0000
Re: What does this code print ? Bo Persson <bo@bo-persson.se> - 2023-10-11 20:24 +0200
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-13 05:24 +0200
Re: What does this code print ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-13 17:53 +0100
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-14 15:50 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-13 12:12 -0400
Re: What does this code print ? scott@slp53.sl.home (Scott Lurndal) - 2023-10-13 17:27 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-14 15:52 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-14 11:26 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 09:08 +0200
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-15 12:55 -0700
Re: What does this code print ? Richard Damon <news.x.richarddamon@xoxy.net> - 2023-10-15 22:19 -0400
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-18 20:58 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-11 19:21 +0200
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-11 12:41 -0700
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-11 12:43 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-13 05:25 +0200
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-12 20:50 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-13 08:50 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-13 12:15 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-14 15:53 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-14 11:26 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 09:00 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-15 13:15 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-17 07:47 +0200
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-17 11:34 -0700
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-13 16:34 +0000
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-13 13:12 -0700
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-14 02:36 +0000
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-13 20:44 -0700
Re: What does this code print ? Paavo Helde <eesnimi@osa.pri.ee> - 2023-10-14 11:51 +0300
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-17 11:35 -0700
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-17 20:06 +0000
Re: What does this code print ? Paavo Helde <eesnimi@osa.pri.ee> - 2023-10-18 11:43 +0300
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-18 17:29 +0000
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-18 11:31 -0700
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-19 14:43 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-14 15:54 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-14 18:05 +0000
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-14 14:58 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 08:58 +0200
Re: What does this code print ? Richard Damon <news.x.richarddamon@xoxy.net> - 2023-10-14 12:47 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 09:07 +0200
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 09:12 +0200
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 09:16 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-15 13:35 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-17 07:48 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-17 23:04 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-19 19:58 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-19 14:39 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-19 19:58 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-19 18:06 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-19 20:11 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-19 19:20 +0000
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-19 16:06 -0400
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-19 14:45 -0700
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-19 23:26 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-20 09:19 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-20 05:47 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-20 17:59 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-20 19:16 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-21 08:02 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-21 08:38 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-21 19:40 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-21 10:54 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-21 20:34 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-21 12:45 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-22 04:18 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-21 19:28 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-22 06:53 +0200
Re: What does this code print ? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2023-10-22 09:59 +0000
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-22 07:12 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-23 19:05 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-23 10:40 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 16:03 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-24 07:28 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 17:01 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-24 08:28 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 18:27 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-24 10:05 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 19:08 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-24 10:39 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 20:25 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-24 19:48 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-25 10:54 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 08:43 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-25 17:57 +0200
Re: What does this code print ? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2023-10-24 16:40 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 19:07 +0200
Re: What does this code print ? scott@slp53.sl.home (Scott Lurndal) - 2023-10-24 15:25 +0000
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-24 08:34 -0700
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-24 16:34 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-24 19:05 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-20 14:50 +0000
Re: What does this code print ? Bo Persson <bo@bo-persson.se> - 2023-10-20 17:34 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-20 15:59 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-20 18:00 +0200
Re: What does this code print ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-10-20 16:06 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-20 18:40 +0200
Re: What does this code print ? gazelle@shell.xmission.com (Kenny McCormack) - 2023-10-20 20:07 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-21 08:04 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-15 13:35 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-17 07:50 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-17 23:08 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-19 20:02 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-19 14:43 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-19 20:02 +0200
Re: What does this code print ? scott@slp53.sl.home (Scott Lurndal) - 2023-10-15 14:36 +0000
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-15 18:15 +0200
Re: What does this code print ? Richard Damon <news.x.richarddamon@xoxy.net> - 2023-10-15 22:23 -0400
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-17 07:51 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-17 23:08 -0400
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-15 13:25 -0400
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-14 11:33 -0700
Re: What does this code print ? Paavo Helde <eesnimi@osa.pri.ee> - 2023-10-14 21:54 +0300
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-14 11:56 -0700
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-24 15:53 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-25 15:07 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 08:43 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-25 18:01 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 09:21 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-25 18:24 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 11:23 -0700
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-25 15:02 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-26 07:13 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 23:09 -0700
Re: What does this code print ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-10-25 23:55 -0400
Re: What does this code print ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-10-25 15:01 -0700
Re: What does this code print ? Bonita Montero <Bonita.Montero@gmail.com> - 2023-10-26 07:15 +0200
Re: What does this code print ? Richard Damon <richard@damon-family.org> - 2023-10-25 23:12 -0700
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-13 05:25 +0200 |
| Message-ID | <ugadbi$2va82$2@dont-email.me> |
| In reply to | #92587 |
Am 11.10.2023 um 21:41 schrieb Chris M. Thomasson:
>> 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;
>>> }
>>>
> Afaict, around 99.(9)% sure, Bonita is a troll.
Yes, because I didn't use a race detector on the above code.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-10-12 20:50 -0700 |
| Message-ID | <ugaeqo$2vefi$1@dont-email.me> |
| In reply to | #92575 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-13 08:50 +0200 |
| Message-ID | <ugapal$31eim$1@dont-email.me> |
| In reply to | #92669 |
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 ...
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-13 12:15 -0400 |
| Message-ID | <ugbqf7$19fre$3@i2pn2.org> |
| In reply to | #92704 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-14 15:53 +0200 |
| Message-ID | <uge6gg$3spt4$3@dont-email.me> |
| In reply to | #92776 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-14 11:26 -0400 |
| Message-ID | <ugebv8$1gabn$2@i2pn2.org> |
| In reply to | #92820 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-15 09:00 +0200 |
| Message-ID | <ugg2li$cf8s$2@dont-email.me> |
| In reply to | #92830 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-15 13:15 -0400 |
| Message-ID | <ugh6nc$1k9qg$1@i2pn2.org> |
| In reply to | #92840 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-17 07:47 +0200 |
| Message-ID | <ugl76a$2pe6u$1@dont-email.me> |
| In reply to | #92861 |
Am 15.10.2023 um 19:15 schrieb Richard Damon: > What make you say that? I know nerds. Rest unread.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-10-17 11:34 -0700 |
| Message-ID | <ugmk4c$347g6$1@dont-email.me> |
| In reply to | #92903 |
On 10/16/2023 10:47 PM, Bonita Montero wrote: > Am 15.10.2023 um 19:15 schrieb Richard Damon: > >> What make you say that? > > I know nerds. > > Rest unread. > You are a special person, Bonita! :^)
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-10-13 16:34 +0000 |
| Message-ID | <20231013081459.652@kylheku.com> |
| In reply to | #92704 |
On 2023-10-13, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> O.k., I'll explain it: the lambda is compiled twice for each cal-
I suspect the terminology you're groping for is "inlined".
> ling convention but in contrast to a generic lambda the thread
I don't believe it. It looks like the lambda uses the default calling
convention ("__cdecl"), and is just being misused through the wrong
calling convention.
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.
(Compiling for a target other than x86 also renders it moot, since
the calling convention extensions are ignored on x64 and arm.
Let's assume they are there for a reason, and we are targetting x86).
Inlining is an optimization.
If your code depends on optimization (or lack thereof) in order to have
the semantics you believe it to have, it's wrong.
If the function is actually called through the wrong conventions,
there will be problems. The fastcall call will put the argument value in
a register, whereas the stdcall function will try to take it from the
stack, resulting in the callee accessing some value unrelated to the
argument.
The stdcall might be able to access the argument value, but under
stdcall, the callee is assumed to remove arguments from the stack
which the cdecl callee will not do. That could leave the stack in
sufficiently bad state that main is not able to return.
Or something; why go too deeply into guessing what incorrect code
might be doing, if we're not actually fighting a fire.
That function inlining doesn't proliferate copies of static or
thread_local variables isn't surprising at all; that's needed to
preserve semantics.
It is generic lambdas that stand in contrast. They are a macro-like
mechanism which duplicates code, due to type inference or template
argument deduction. They are also newer.
--
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.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-10-13 13:12 -0700 |
| Message-ID | <ugc8bo$3cv2m$1@dont-email.me> |
| In reply to | #92777 |
On 10/13/2023 9:34 AM, Kaz Kylheku wrote:
> On 2023-10-13, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> O.k., I'll explain it: the lambda is compiled twice for each cal-
>
> I suspect the terminology you're groping for is "inlined".
>
>> ling convention but in contrast to a generic lambda the thread
>
> I don't believe it. It looks like the lambda uses the default calling
> convention ("__cdecl"), and is just being misused through the wrong
> calling convention.
>
> 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.
> (Compiling for a target other than x86 also renders it moot, since
> the calling convention extensions are ignored on x64 and arm.
> Let's assume they are there for a reason, and we are targetting x86).
>
> Inlining is an optimization.
>
> If your code depends on optimization (or lack thereof) in order to have
> the semantics you believe it to have, it's wrong.
>
> If the function is actually called through the wrong conventions,
> there will be problems. The fastcall call will put the argument value in
> a register, whereas the stdcall function will try to take it from the
> stack, resulting in the callee accessing some value unrelated to the
> argument.
>
> The stdcall might be able to access the argument value, but under
> stdcall, the callee is assumed to remove arguments from the stack
> which the cdecl callee will not do. That could leave the stack in
> sufficiently bad state that main is not able to return.
>
> Or something; why go too deeply into guessing what incorrect code
> might be doing, if we're not actually fighting a fire.
>
> That function inlining doesn't proliferate copies of static or
> thread_local variables isn't surprising at all; that's needed to
> preserve semantics.
Afaict, thread_local should be using the thread that is calling main in
this example.
I should create a new thread for this, but:
Fwiw, actually, I am trying to understand how dtors are called wrt TLS
when a thread is destroyed (aka, join returns) in C++. POSIX and C11
makes this rather easy wrt:
Notice the dtor that we can use wrt (thread local storage) TLS:
https://en.cppreference.com/w/c/thread/tss_create
This is basically how POSIX does it via:
pthread_key_t
_______________
pthread_key_create
pthread_setspecific
pthread_getspecific
pthread_key_delete
_______________
Easy.
>
> It is generic lambdas that stand in contrast. They are a macro-like
> mechanism which duplicates code, due to type inference or template
> argument deduction. They are also newer.
>
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-10-14 02:36 +0000 |
| Message-ID | <20231013192405.57@kylheku.com> |
| In reply to | #92802 |
On 2023-10-13, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > Afaict, thread_local should be using the thread that is calling main in > this example. If the program has not started any threads, so that there is only the primary thread that starts at main, thread_local could be replaced by static. > I should create a new thread for this, but: > > Fwiw, actually, I am trying to understand how dtors are called wrt TLS > when a thread is destroyed (aka, join returns) in C++. POSIX and C11 > makes this rather easy wrt: > > Notice the dtor that we can use wrt (thread local storage) TLS: > > https://en.cppreference.com/w/c/thread/tss_create > > This is basically how POSIX does it via: > > pthread_key_t > _______________ > pthread_key_create > pthread_setspecific > pthread_getspecific > pthread_key_delete > _______________ The pthread_key_delete function is rarely needed. We would need it in, say, a dynamically loaded component that is being unloaded. Usually keys have an indefinite lifetime. The values don't, of course. In pthread_key_create we can register a destructor function that is used upon thread death. This is extremely badly designed in POSIX, because that thread which is terminated is tasked with the clean-up of the keys: the destructors run in its context. While it's performing the clean-up for one key, it might inadvertently call some code which reinstalls the value for another key. In recognition of this problem, the API is designed with a silly iteration mechanism. If the terminating thread has reinstanted values for any thread specific keys, those are iterated on again and the destructors are called, up to some number of times. What you want is to allow the thread to just exit. In that thread's context, at most you want to do unwinding of its scoped resources. The thread-specific keys values of a thread should persist until it has terminated, and then be cleaned up at some later time by *another* thread. Kind of like a garbage collection pass. If the thread is pthread_join-ed, the one doing the joining would be a good candidate. For detached threads, it could be done by some internal thread, or foisted onto some existing application thread when it happens to bump into the pthread key API. That would prevent the need for iterations because, since another thread is running the destructors, and not the original one, That other thread can only set its own key values, and not those of another thread, let alone a dead one. Some 25 years ago I made a TLS API like that, with the cleanup done on another thread. It worked well. -- 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.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-10-13 20:44 -0700 |
| Message-ID | <ugd2r5$3ls76$1@dont-email.me> |
| In reply to | #92813 |
On 10/13/2023 7:36 PM, Kaz Kylheku wrote: > On 2023-10-13, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> Afaict, thread_local should be using the thread that is calling main in >> this example. > > If the program has not started any threads, so that there is only > the primary thread that starts at main, thread_local could be > replaced by static. > >> I should create a new thread for this, but: >> >> Fwiw, actually, I am trying to understand how dtors are called wrt TLS >> when a thread is destroyed (aka, join returns) in C++. POSIX and C11 >> makes this rather easy wrt: >> >> Notice the dtor that we can use wrt (thread local storage) TLS: >> >> https://en.cppreference.com/w/c/thread/tss_create >> >> This is basically how POSIX does it via: >> >> pthread_key_t >> _______________ >> pthread_key_create >> pthread_setspecific >> pthread_getspecific >> pthread_key_delete >> _______________ > > The pthread_key_delete function is rarely needed. We would need it in, > say, a dynamically loaded component that is being unloaded. > > Usually keys have an indefinite lifetime. The values don't, of course. > > In pthread_key_create we can register a destructor function > that is used upon thread death. > > This is extremely badly designed in POSIX, because that thread which is > terminated is tasked with the clean-up of the keys: the destructors > run in its context. Sorry for the brief response. Actually, I never had a problem with it in my code before. However, I have had to debug some code created by others. Should have some more time tomorrow to code some tests up. Am curious if some of my C compilers support C11 threads yet like Pelles C: http://www.smorgasbordet.com/pellesc/ [...]
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2023-10-14 11:51 +0300 |
| Message-ID | <ugdkql$3p94s$1@dont-email.me> |
| In reply to | #92813 |
14.10.2023 05:36 Kaz Kylheku kirjutas: > > The thread-specific keys values of a thread should persist until it > has terminated, and then be cleaned up at some later time by > *another* thread. Kind of like a garbage collection pass. So, a destructor of an object which has specifically declared to live in a single thread only, will be called in some other thread? Sure, seems very intuitive, what might go wrong!
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-10-17 11:35 -0700 |
| Message-ID | <ugmk55$347g6$2@dont-email.me> |
| In reply to | #92816 |
On 10/14/2023 1:51 AM, Paavo Helde wrote: > 14.10.2023 05:36 Kaz Kylheku kirjutas: >> >> The thread-specific keys values of a thread should persist until it >> has terminated, and then be cleaned up at some later time by >> *another* thread. Kind of like a garbage collection pass. > > So, a destructor of an object which has specifically declared to live in > a single thread only, will be called in some other thread? > > Sure, seems very intuitive, what might go wrong! Ditto.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-10-17 20:06 +0000 |
| Message-ID | <20231017125440.439@kylheku.com> |
| In reply to | #93029 |
On 2023-10-17, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > On 10/14/2023 1:51 AM, Paavo Helde wrote: >> 14.10.2023 05:36 Kaz Kylheku kirjutas: >>> >>> The thread-specific keys values of a thread should persist until it >>> has terminated, and then be cleaned up at some later time by >>> *another* thread. Kind of like a garbage collection pass. >> >> So, a destructor of an object which has specifically declared to live in >> a single thread only, will be called in some other thread? >> >> Sure, seems very intuitive, what might go wrong! > > Ditto. Objects don't literally live in threads. Objects live in an address space. This is exactly like finalization of unreachable objects in managed environments. If a thread holds some objects which are only accessible to it, when that thraed terminates, they become garbage. They necessarily get reclaimed by a different thread, and that one will run their finalization hooks, if any. If an object is used by only one thread during its lifetime, that means that it doesn't require locking. However, the thread which reclaims the object does not run at the same time as the thread which died, so there is no race between the two. That aspect of it is fine. The destructor cannot make the assumption that it is executed by that same thread. E.g. if the object contained a stashed copy of the thread ID of the original thread, the destructor would be wrong to assume that the the thread which is executing it corresponds to that ID. -- 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.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2023-10-18 11:43 +0300 |
| Message-ID | <ugo5ra$3i2k3$1@dont-email.me> |
| In reply to | #93043 |
17.10.2023 23:06 Kaz Kylheku kirjutas: > On 2023-10-17, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 10/14/2023 1:51 AM, Paavo Helde wrote: >>> 14.10.2023 05:36 Kaz Kylheku kirjutas: >>>> >>>> The thread-specific keys values of a thread should persist until it >>>> has terminated, and then be cleaned up at some later time by >>>> *another* thread. Kind of like a garbage collection pass. >>> >>> So, a destructor of an object which has specifically declared to live in >>> a single thread only, will be called in some other thread? >>> >>> Sure, seems very intuitive, what might go wrong! >> >> Ditto. > > Objects don't literally live in threads. Objects live in an address > space. > > This is exactly like finalization of unreachable objects in managed > environments. That's something we want to avoid, not to replicate. > If a thread holds some objects which are only accessible > to it, when that thraed terminates, they become garbage. They > necessarily get reclaimed by a different thread, and that one will > run their finalization hooks, if any. We have been through that, here, long time ago, with a lot of pain and suffering. The consensus reached was that if/when supporting something like garbage collection in C++, only the occupied memory should be released by GC. The destructors of objects should not be run, because that would happen in a non-predictable thread at non-predictable time, making the program non-deterministic. To be honest, your idea to run the destructors during the thread join makes it a bit more deterministic, so it is somewhat better.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-10-18 17:29 +0000 |
| Message-ID | <20231018102525.515@kylheku.com> |
| In reply to | #93207 |
On 2023-10-18, Paavo Helde <eesnimi@osa.pri.ee> wrote: > We have been through that, here, long time ago, with a lot of pain and > suffering. The consensus reached was that if/when supporting something > like garbage collection in C++, only the occupied memory should be > released by GC. Well, this isn't that discussion; it's about a clean up of thread-specfic keys when a thread dies. No GC-like reachability analysis is required; the thread explicitly terminated and so we know the key bindings are garbage, requiring destruction. That is handed to us. There are advantages to not doing that cleanup in the context of the thread which died. > The destructors of objects should not be run, because > that would happen in a non-predictable thread at non-predictable time, > making the program non-deterministic. If you what deterministic, don't use these things called threads? -- 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.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-10-18 11:31 -0700 |
| Message-ID | <ugp89p$3pur8$2@dont-email.me> |
| In reply to | #93311 |
On 10/18/2023 10:29 AM, Kaz Kylheku wrote: > On 2023-10-18, Paavo Helde <eesnimi@osa.pri.ee> wrote: >> We have been through that, here, long time ago, with a lot of pain and >> suffering. The consensus reached was that if/when supporting something >> like garbage collection in C++, only the occupied memory should be >> released by GC. > > Well, this isn't that discussion; it's about a clean up of > thread-specfic keys when a thread dies. I must be misunderstanding you here. However, we do not need to create a thread-specific key on a per thread basis. One key per process works fine.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web