Date: Wed, 8 Jun 2022 15:04:05 -0400
On 6/8/22 14:36, Daniel Ruoso via Core wrote:
> Em qua., 8 de jun. de 2022 às 13:23, Nathan Sidwell via SG15
> <sg15_at_[hidden]> escreveu:
>> 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?
>
> The term "implementation partition" is a bit confusing, because it
> communicates it's close to what "implementation unit" is. We've
> settled on using "internal partition" instead, as that more clearly
> communicates what it does.
>
>> I don't think we require implementation partitions
>> be imported at least once in a program.
>
> If a tree falls in a forest and no one is around to hear it, does it
> make a sound?
>
> You're not required to import in any *specific* unit, but if you don't
> import anywhere, then nothing can see it.
>
> The flexibility here is that you can have internal partitions that are
> not reachable by the interface and therefore don't need to be
> distributed with the interface. But for them to be useful, they still
> need to be reachable by something (presumably the implementation
> unit).
Correct, such partitions would usually be imported by (more than one) TU
of the module. Otherwise, what are you doing?
>
>> 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
>
> I think this is already the case with global initializers in objects
> that end up not being linked from an archive, so I don't think it's
> without precedent to just accept that if you never import a module, it
> is just not going to be linked in any meaningful way.
[unix] tools treat the following differently:
ld main.o unused.o
or
ar -c libunused.a unused.o
ld main.o -L. -lunused
the former will place unused.o into the executable, that latter will
not. In a non-module world the former will have unused.o's global
static initializers run. The latter obviously won't because they're not
there.
>
> daniel
> _______________________________________________
> Core mailing list
> Core_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post: http://lists.isocpp.org/core/2022/06/12645.php
> Em qua., 8 de jun. de 2022 às 13:23, Nathan Sidwell via SG15
> <sg15_at_[hidden]> escreveu:
>> 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?
>
> The term "implementation partition" is a bit confusing, because it
> communicates it's close to what "implementation unit" is. We've
> settled on using "internal partition" instead, as that more clearly
> communicates what it does.
>
>> I don't think we require implementation partitions
>> be imported at least once in a program.
>
> If a tree falls in a forest and no one is around to hear it, does it
> make a sound?
>
> You're not required to import in any *specific* unit, but if you don't
> import anywhere, then nothing can see it.
>
> The flexibility here is that you can have internal partitions that are
> not reachable by the interface and therefore don't need to be
> distributed with the interface. But for them to be useful, they still
> need to be reachable by something (presumably the implementation
> unit).
Correct, such partitions would usually be imported by (more than one) TU
of the module. Otherwise, what are you doing?
>
>> 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
>
> I think this is already the case with global initializers in objects
> that end up not being linked from an archive, so I don't think it's
> without precedent to just accept that if you never import a module, it
> is just not going to be linked in any meaningful way.
[unix] tools treat the following differently:
ld main.o unused.o
or
ar -c libunused.a unused.o
ld main.o -L. -lunused
the former will place unused.o into the executable, that latter will
not. In a non-module world the former will have unused.o's global
static initializers run. The latter obviously won't because they're not
there.
>
> daniel
> _______________________________________________
> Core mailing list
> Core_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post: http://lists.isocpp.org/core/2022/06/12645.php
-- Nathan Sidwell
Received on 2022-06-08 19:04:07