C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Translation-unit-local functions that access private class fields

From: Thiago Macieira <thiago_at_[hidden]>
Date: Sat, 20 Jun 2026 11:30:24 -0700
On Friday, 19 June 2026 23:04:04 Pacific Daylight Time Sebastian Wittmeier via
Std-Proposals wrote:
> A) Write into the standard that all the tokens of a PEMs declaration have to
> come from the highest level C++ file and not from tokens included by
> #include. How about preprocessor macros? May the whole PEM or parts of it /
> single identifiers or constants come from a #define?
>
>
> B) The PEMs have external linkage. A redefinition with the same or different
> code leads to a linker error. That would also affect PEMs, which are just
> replicated, but would have the exact same code. So a PEM name (although
> they are meant to be private and local) would not be allowed to be reused
> anywhere. That affects helper functions.
>
>
> C) The PEM has internal linkage. While a redefinition (or putting it into a
> header) is not advised due to code duplication, it works just fine in
> practice or is even efficient with link-time-optimization.
>
>
> D) Like C, but redefining it is "ill-formed, no diagnostic required". Could
> work in practice, but the standard forbids it to disencentivize the
> programming practice.

How about: "exactly like what we're already used to"?

Declarations inside the class body don't define any symbols. Implementations
inside the class body and those marked inline are inlineable and must be
token-exact the same in all translation units, otherwise ODR. Out-of-body
implementations without inline are in a single TU, otherwise ODR.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.

Received on 2026-06-20 18:30:31