czw., 30 kwi 2026 o 12:21 Sebastian Wittmeier via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> Yes, a class does *not* have a single specific TU it resides in.
>
>
>
> Several TUs may include the declaration.
>
> The definitions of member functions and variables can be distributed over several TUs.
>
> Template member functions and inlined functions can be generated by multiple TUs and the linker removes the multiple equal symbols.
>
>
>
> (Given: There are TUs, which have the above elements, and there are TUs, which don't.)
>
>
>
> C++ does not have a strong relationship between TU and classes, other languages do. (E.g. in Java typically the .java source files are called like the Classes and the directories signify the package).
>
>

But we have modules where you could assign a specific TU or at least a
group of it as module can be partitioned.

>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Rhidian De Wit via Std-Proposals <std-proposals_at_[hidden]>
> Gesendet: Do 30.04.2026 10:49
> Betreff: Re: [std-proposals] Translation-unit-local functions that access private class fields
> An: std-proposals_at_[hidden];
> CC: Rhidian De Wit <rhidiandewit_at_[hidden]>;
>
>
>
>
>
> I did this mistake sometime at the beginning of this discussion as well: There is some sort of permission control: some public function needs to call your private function directly or indirectly (i.e. through other protected/private functions). It does not matter if you add private functions if they cannot be called. So, yes anybody can add a private function anywhere in the source code. No, they can’t use it (without some weird tricks that might be possible even right now). The only place where this makes sense is in the implementation TU of the class. We need to at least declare the hidden private functions before they can be accessed by other member functions of the class.
>
>
>
>
>
> This could be a mandate: That PEMs are only part of the translation unit of the class they’re extending. So, declaring a PEM in a header becomes impossible, but then how would one create PEMs for template classes? As those are just in headers and will be part of multiple TUs.
>
> Would it not be possible for the compiler to consider the PEM functions via ADL? Assuming that overloaded PEM functions (ergo: no conflict with the originally declared member-functions) are not allowed.
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals