Date: Sun, 25 Jun 2023 14:25:35 -0700
On Sunday, 25 June 2023 12:13:59 PDT Julien Villemure-Fréchette via Std-
Proposals wrote:
> This proposal is most related to ABI, and I think this would be out of scope
> for the specification of C++ language; the specification is strictly
> concerned about language level semantics (the _abstract machine_) and
> specifies no more requirements on implementation details than is necessary
> to permit concrete implementations achieve a maximum level of semantic
> consistency (portability) of the *source code* (with a strong emphasis),
> while keeping it possible to implement in an efficient way. See section 4.1
> [intro.compliance]; it defines the scope of the C++ standard. Any formal
> specification clearly indicates its scope, thereby limiting how it can
> eventually evolve. Such a distinction is important to make the
> specification evolve in a direction which is consistent with the original
> intents and objectives of it.
I disagree with such a limiting definition. The standard can still concern
itself with the abstract machine, but it wouldn't hurt the language to
standardise what every compiler needs to implement today in one of two well-
known extensions We should face reality and accept that libraries do exist and
seek to make them easier to deal with, at least from inside the language.
That said, there are a lot of pitfalls to be addressed. This proposal doesn't
even begin to looking into thinking of scratching the surface of the problem.
It's more of a statement of intent. Libraries, should we decide to explore
them, would probably require a full Study Group.
> The current working draft makes no normative statement on the concrete
> entities that represents translated TUs (the so called object filed), how
> they are organized (both internally and externally) or how they interact
> (ie how they communicate). Hence, adding specific requirements that would
> only affect the nature or morphology of translated TUs, is just immaterial
> as it has no observable interaction with the rest of the standard. Unless
> the abstract concept of "shared library" is defined in section 5 [lex] and
> referred to elsewhere in the standard, such an entity name is no more
> special than other external name other than being marked as such. Hence, a
> conforming implementation could as well just get this entity from an object
> file statically as there is no material difference (yet) between obtaining
> the entity from a static lib, a shared lib, or even anywhere the build tool
> might have chosen. That's unless you further propose an actual *formal
> specification* of what's a shared lib (and also what's library at all).
> Your definition will need to cope with the possibility that an
> implementation might not have a dynamic linker (ie, a loader), or even a
> linker at all. What about freestanding implementations, or an
> implementation that is a C++ interpreter (which is not precluded, as it can
> legitimately implement the semantics of the "abstract machine" which is the
> subject of the formal specification), etc.
All true and all completely irrelevant, because all of the above needs to
still be possible after adding some language to support the existence of
libraries. In other words, whatever language gets added can't remove the
freedoms that implementations may still need. Implementations without files or
freestanding or what have you can fit into one of the possibilities allowed by
the standard. What matters is that *if* you have one of those libraries, the
behaviour is what the standard specified.
Note I said "may still need". The standard hasn't recently shied away from
removing freedoms that were deemed unnecessary, like non-complement-of-2
conversion.
> The standard doesn't go into the details of how "separate compilation", and
> goes no further than translation units as the fundamental structure of
> program fragment, as there would be a countably infinite number of equally
> legitimate ways to implement a (conforming) program so as to observe
> mandated behavior.
Proposals wrote:
> This proposal is most related to ABI, and I think this would be out of scope
> for the specification of C++ language; the specification is strictly
> concerned about language level semantics (the _abstract machine_) and
> specifies no more requirements on implementation details than is necessary
> to permit concrete implementations achieve a maximum level of semantic
> consistency (portability) of the *source code* (with a strong emphasis),
> while keeping it possible to implement in an efficient way. See section 4.1
> [intro.compliance]; it defines the scope of the C++ standard. Any formal
> specification clearly indicates its scope, thereby limiting how it can
> eventually evolve. Such a distinction is important to make the
> specification evolve in a direction which is consistent with the original
> intents and objectives of it.
I disagree with such a limiting definition. The standard can still concern
itself with the abstract machine, but it wouldn't hurt the language to
standardise what every compiler needs to implement today in one of two well-
known extensions We should face reality and accept that libraries do exist and
seek to make them easier to deal with, at least from inside the language.
That said, there are a lot of pitfalls to be addressed. This proposal doesn't
even begin to looking into thinking of scratching the surface of the problem.
It's more of a statement of intent. Libraries, should we decide to explore
them, would probably require a full Study Group.
> The current working draft makes no normative statement on the concrete
> entities that represents translated TUs (the so called object filed), how
> they are organized (both internally and externally) or how they interact
> (ie how they communicate). Hence, adding specific requirements that would
> only affect the nature or morphology of translated TUs, is just immaterial
> as it has no observable interaction with the rest of the standard. Unless
> the abstract concept of "shared library" is defined in section 5 [lex] and
> referred to elsewhere in the standard, such an entity name is no more
> special than other external name other than being marked as such. Hence, a
> conforming implementation could as well just get this entity from an object
> file statically as there is no material difference (yet) between obtaining
> the entity from a static lib, a shared lib, or even anywhere the build tool
> might have chosen. That's unless you further propose an actual *formal
> specification* of what's a shared lib (and also what's library at all).
> Your definition will need to cope with the possibility that an
> implementation might not have a dynamic linker (ie, a loader), or even a
> linker at all. What about freestanding implementations, or an
> implementation that is a C++ interpreter (which is not precluded, as it can
> legitimately implement the semantics of the "abstract machine" which is the
> subject of the formal specification), etc.
All true and all completely irrelevant, because all of the above needs to
still be possible after adding some language to support the existence of
libraries. In other words, whatever language gets added can't remove the
freedoms that implementations may still need. Implementations without files or
freestanding or what have you can fit into one of the possibilities allowed by
the standard. What matters is that *if* you have one of those libraries, the
behaviour is what the standard specified.
Note I said "may still need". The standard hasn't recently shied away from
removing freedoms that were deemed unnecessary, like non-complement-of-2
conversion.
> The standard doesn't go into the details of how "separate compilation", and
> goes no further than translation units as the fundamental structure of
> program fragment, as there would be a countably infinite number of equally
> legitimate ways to implement a (conforming) program so as to observe
> mandated behavior.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-06-25 21:25:37