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 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-20 18:00 +0200 |
| Message-ID | <ugu879$1685u$2@dont-email.me> |
| In reply to | #94254 |
Am 20.10.2023 um 16:50 schrieb Kaz Kylheku: > Uh, yes it obviously is! The lambda is declared without any calling > conventions attributes, but the function pointer has them. The lambda is compiled for each destination pointer's calling convention. > Are the tokens lexically analyzed twice? As I described both compiled functions to the same and share static and thread-local variables. Rest unread.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-10-20 16:06 +0000 |
| Message-ID | <20231020090555.863@kylheku.com> |
| In reply to | #94263 |
On 2023-10-20, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 20.10.2023 um 16:50 schrieb Kaz Kylheku: > >> Uh, yes it obviously is! The lambda is declared without any calling >> conventions attributes, but the function pointer has them. > > The lambda is compiled for each destination pointer's calling convention. At this point you're just stringing together computer sciency words. -- 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 | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-20 18:40 +0200 |
| Message-ID | <uguai0$16sc9$1@dont-email.me> |
| In reply to | #94265 |
Am 20.10.2023 um 18:06 schrieb Kaz Kylheku: > At this point you're just stringing together computer sciency words. The calling convention is part of the function pointer.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2023-10-20 20:07 +0000 |
| Message-ID | <uguml4$2eo3g$1@news.xmission.com> |
| In reply to | #94267 |
In article <uguai0$16sc9$1@dont-email.me>,
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 20.10.2023 um 18:06 schrieb Kaz Kylheku:
>
>> At this point you're just stringing together computer sciency words.
>
>The calling convention is part of the function pointer.
>
>
At this point you're just stringing together computer sciency words.
Quoting The Rockford Files:
We're ghosting at 9600 Kbaud.
--
It's possible that leasing office space to a Starbucks is a greater liability
in today's GOP than is hitting your mother on the head with a hammer.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-21 08:04 +0200 |
| Message-ID | <ugvpke$1jsdj$1@dont-email.me> |
| In reply to | #94296 |
Am 20.10.2023 um 22:07 schrieb Kenny McCormack:
> In article <uguai0$16sc9$1@dont-email.me>,
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> The calling convention is part of the function pointer.
> At this point you're just stringing together computer sciency words.
> Quoting The Rockford Files:
Look at this:
int (__fastcall *volatile pFnFastcall)( int ) = lambda;
int (__stdcall *volatile pFnStdcall)( int ) = lambda;
This are functin pointers with separate calling conventions.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-15 13:35 -0400 |
| Message-ID | <ugh7se$1k9qh$4@i2pn2.org> |
| In reply to | #92843 |
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).
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-17 07:50 +0200 |
| Message-ID | <ugl7b1$2pe6u$3@dont-email.me> |
| In reply to | #92864 |
Am 15.10.2023 um 19:35 schrieb Richard Damon: > 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 You can see from the RET (xxx) that these are separate functions. And the functions couldn't be inlined because I hide them behind volatile function ponters. > Thus it isn't that you got "two different lambda" with different calling > convention refencing the same variable, but you have ONE lambda, ... Seems you're not able to read assembly.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-17 23:08 -0400 |
| Message-ID | <ugni73$1t8hq$2@i2pn2.org> |
| In reply to | #92905 |
On 10/17/23 1:50 AM, Bonita Montero wrote: > Am 15.10.2023 um 19:35 schrieb Richard Damon: >> 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 > > You can see from the RET (xxx) that these are separate functions. > And the functions couldn't be inlined because I hide them behind > volatile function ponters. Nope at the final CALL site, it needs to call through the pointer, but the pointer needs to create the functions, which are wrappers around a single function, which happens to be inlined for the two instances. > >> Thus it isn't that you got "two different lambda" with different >> calling convention refencing the same variable, but you have ONE >> lambda, ... > > Seems you're not able to read assembly. > No, I read it perfectly fine. Do you not understand how inlining works? Or how the compiler needs to generate the out of line copy of in line functions? The fact that they share a local scope 'static' variable says they must be copies of the same inline function.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-19 20:02 +0200 |
| Message-ID | <ugrquu$fto1$2@dont-email.me> |
| In reply to | #93133 |
Am 18.10.2023 um 05:08 schrieb Richard Damon: > On 10/17/23 1:50 AM, Bonita Montero wrote: >> You can see from the RET (xxx) that these are separate functions. >> And the functions couldn't be inlined because I hide them behind >> volatile function ponters. > Nope at the final CALL site, it needs to call through the pointer, but > the pointer needs to create the functions, which are wrappers around a > single function, which happens to be inlined for the two instances. I've traced through the code and both functions are directly called from the volatile function pointers and both functions do what the C++ code shows. If they would be invokers both functions wouldn't have to deal with thread-local storate through the FS-segment. > Do you not understand how inlining works? The functions aren't inlined because the function pointers are volatile.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-19 14:43 -0400 |
| Message-ID | <ugrtce$238ca$3@i2pn2.org> |
| In reply to | #94114 |
On 10/19/23 2:02 PM, Bonita Montero wrote: > Am 18.10.2023 um 05:08 schrieb Richard Damon: > >> On 10/17/23 1:50 AM, Bonita Montero wrote: > >>> You can see from the RET (xxx) that these are separate functions. >>> And the functions couldn't be inlined because I hide them behind >>> volatile function ponters. > >> Nope at the final CALL site, it needs to call through the pointer, but >> the pointer needs to create the functions, which are wrappers around a >> single function, which happens to be inlined for the two instances. > > I've traced through the code and both functions are directly called > from the volatile function pointers and both functions do what the > C++ code shows. If they would be invokers both functions wouldn't > have to deal with thread-local storate through the FS-segment. Yes, the call through the pointer isn't inlined, because that would violate the symantics of the volatile. The calls inside the invokers IS inlined, because there it know exactly what function is being called. So, you are seeing two invoker thunks to the same function, but that function has been inlined into the two invoker thunks. > >> Do you not understand how inlining works? > > The functions aren't inlined because the function pointers are volatile. > So, you don't understand what happens when you take the address of an inline function?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-19 20:02 +0200 |
| Message-ID | <ugrqve$fsmt$2@dont-email.me> |
| In reply to | #93133 |
Am 18.10.2023 um 05:08 schrieb Richard Damon: > On 10/17/23 1:50 AM, Bonita Montero wrote: >> You can see from the RET (xxx) that these are separate functions. >> And the functions couldn't be inlined because I hide them behind >> volatile function ponters. > Nope at the final CALL site, it needs to call through the pointer, but > the pointer needs to create the functions, which are wrappers around a > single function, which happens to be inlined for the two instances. I've traced through the code and both functions are directly called from the volatile function pointers and both functions do what the C++ code shows. If they would be invokers both functions wouldn't have to deal with thread-local storate through the FS-segment. > Do you not understand how inlining works? The functions aren't inlined because the function pointers are volatile.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-10-15 14:36 +0000 |
| Message-ID | <5OSWM.54624$tnmf.54137@fx09.iad> |
| In reply to | #92841 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-15 18:15 +0200 |
| Message-ID | <ugh375$jdrk$1@dont-email.me> |
| In reply to | #92856 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2023-10-15 22:23 -0400 |
| Message-ID | <ugi6q6$ulpp$2@dont-email.me> |
| In reply to | #92858 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-10-17 07:51 +0200 |
| Message-ID | <ugl7c6$2pe6u$4@dont-email.me> |
| In reply to | #92874 |
Am 16.10.2023 um 04:23 schrieb Richard Damon: > 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. As I said you're a nerd. > Platform specific code, when not restricted to the platform, is often > undefined in the more general world.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-17 23:08 -0400 |
| Message-ID | <ugni7p$1t8hq$3@i2pn2.org> |
| In reply to | #92906 |
On 10/17/23 1:51 AM, Bonita Montero wrote: > Am 16.10.2023 um 04:23 schrieb Richard Damon: >> 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. > > As I said you're a nerd. > And your an idiot troll. >> Platform specific code, when not restricted to the platform, is often >> undefined in the more general world. >
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2023-10-15 13:25 -0400 |
| Message-ID | <ugh7b6$1k9qh$2@i2pn2.org> |
| In reply to | #92841 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-10-14 11:33 -0700 |
| Message-ID | <ugemtr$61v$1@dont-email.me> |
| In reply to | #92704 |
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...
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2023-10-14 21:54 +0300 |
| Message-ID | <ugeo5l$gqp$1@dont-email.me> |
| In reply to | #92833 |
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).
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-10-14 11:56 -0700 |
| Message-ID | <ugeo9l$61v$3@dont-email.me> |
| In reply to | #92834 |
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.
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web