Date: Wed, 8 Jun 2022 18:41:53 +0000
Nathan -
I am not sure I understand the issue. How would a program observe that an implementation partition isn't imported but is relevant to the behavior of the entire program?
-- Gaby
-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Nathan Sidwell via SG15
Sent: Wednesday, June 8, 2022 10:23 AM
To: C++ Core Language Working Group <core_at_[hidden]>; sg15_at_[hidden]
Cc: Nathan Sidwell <nathan_at_[hidden]>
Subject: [SG15] unimported implementation partitions
Q1) Is there a use case for implementation partitions (a non-interface
partition) that are not imported in any module unit? How would that
differ from a regular implementation partition?
We require all interface partitions be [transitively] imported in the
primary interface. I don't think we require implementation partitions
be imported at least once in a program.
Q2) Is there a use case for a program to include a module interface that
is not imported in any other TU (and has no implementation units)?
The reason I ask is there an ABI issue with the global initializer
function needed for p1874. I'm going to describe it in ELF terms, but I
imagine the same choices appear in other ABIs.
1874 is solved by having each module primary interface, and all
partitions, emit an idempotent initialization function that (a) calls
the init fn of all imports and then (b) performs all dynamic inits of
namespace scope.
In a non-module world a function that performs #b would then arrange to
be called at startup via .init or similar. In a module-world, we do not
(need to) do this, as we know it'll be called somewhere by an import.
However, Q1 raises the possibility that an implementation partition may
not be imported anywhere, so its global initializer fn is never called
from another global init. We therefore have to arrange for it to be
called from .init as a regular initializer function. A small pessimization.
Q2 raises the same question wrt primary interfaces. If they might never
be imported, again, their initializer fn would never be called by that
mechanism. We have to emit it via .init.
nathan
I am not sure I understand the issue. How would a program observe that an implementation partition isn't imported but is relevant to the behavior of the entire program?
-- Gaby
-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Nathan Sidwell via SG15
Sent: Wednesday, June 8, 2022 10:23 AM
To: C++ Core Language Working Group <core_at_[hidden]>; sg15_at_[hidden]
Cc: Nathan Sidwell <nathan_at_[hidden]>
Subject: [SG15] unimported implementation partitions
Q1) Is there a use case for implementation partitions (a non-interface
partition) that are not imported in any module unit? How would that
differ from a regular implementation partition?
We require all interface partitions be [transitively] imported in the
primary interface. I don't think we require implementation partitions
be imported at least once in a program.
Q2) Is there a use case for a program to include a module interface that
is not imported in any other TU (and has no implementation units)?
The reason I ask is there an ABI issue with the global initializer
function needed for p1874. I'm going to describe it in ELF terms, but I
imagine the same choices appear in other ABIs.
1874 is solved by having each module primary interface, and all
partitions, emit an idempotent initialization function that (a) calls
the init fn of all imports and then (b) performs all dynamic inits of
namespace scope.
In a non-module world a function that performs #b would then arrange to
be called at startup via .init or similar. In a module-world, we do not
(need to) do this, as we know it'll be called somewhere by an import.
However, Q1 raises the possibility that an implementation partition may
not be imported anywhere, so its global initializer fn is never called
from another global init. We therefore have to arrange for it to be
called from .init as a regular initializer function. A small pessimization.
Q2 raises the same question wrt primary interfaces. If they might never
be imported, again, their initializer fn would never be called by that
mechanism. We have to emit it via .init.
nathan
-- Nathan Sidwell _______________________________________________ SG15 mailing list SG15_at_[hidden] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7Cb02f9c80f73f430ebcc308da49738f33%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637903057917268486%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dzZXW8p0klJXSqPVpHRCjthTLCf38Jki6lnH9mREtUY%3D&reserved=0
Received on 2022-06-08 18:41:55