Date: Mon, 3 Apr 2023 14:44:00 +0100
On Sun, 2 Apr 2023 at 15:52, Julian Waters via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Hi everyone, sorry if this is a bit of a silly idea, I'm rather new to the
> C++ Standard proposal lists,
>
> I've noticed that other than for language linkage in compiled object
> files, neither C nor C++ have a concept of what a library is, except
> for the following described in the phases of compilation:
>
> "Translation units, instantiation units, and library components needed to
> satisfy external references are collected into a program image which
> contains information needed for execution in its execution environment."
>
N.B. This is talking about components from the C++ standard library, it's
not talking about "libraries" in the sense that you're talking about them.
>
> Of course, this is kept vague for flexibility, which makes sense. But
> given that libraries themselves are also often written in C and C++ themselves,
> it becomes messy when trying to export code from them for use in other
> executables, with chains of conditionals guarding macro definitions and
> so on.
>
> Currently, C++ only defines a program image in terms of an executable in the
> corresponding execution environment, so that the main function can be
> well defined within the language itself. Would it be possible to extend this
> definition slightly to include a very minimalistic definition of
> libraries in the language as well, alongside language features specific to
> libraries to export functions?
>
> """
> +++ Any executable program +++ shall contain a global function called
> main. Executing a program starts a main thread of execution (6.8.2, 33.3)
> in which the main function is invoked, and in which variables of static
> storage duration might be initialized (6.8.3.2) and destroyed (6.8.3.4).
> +++ It is implementation-defined whether an executable program in a
> freestanding environment is required to define a main function. Library
> programs cannot contain main functions. +++
> """
>
There are no "library programs". Libraries are fragments of a program, not
complete programs. Since you can't execute a library, the C++ standard
doesn't need to say anything about them. They're just a way of grouping
translation units together for inclusion in a complete program, and the
standard already talks about translation units and programs.
You say that the aim is to define mechanisms for controlling exports from
libraries, which might well be useful, but the change suggested above
doesn't give us that, and doesn't actually achieve anything. It seems like
a completely meaningless change (especially as you haven't added any
wording to define what "executable program" and "library program" actually
mean here).
The proposal
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0275r4.html has
links to past proposals related to shared libraries, you might find it
helpful to read those.
std-proposals_at_[hidden]> wrote:
> Hi everyone, sorry if this is a bit of a silly idea, I'm rather new to the
> C++ Standard proposal lists,
>
> I've noticed that other than for language linkage in compiled object
> files, neither C nor C++ have a concept of what a library is, except
> for the following described in the phases of compilation:
>
> "Translation units, instantiation units, and library components needed to
> satisfy external references are collected into a program image which
> contains information needed for execution in its execution environment."
>
N.B. This is talking about components from the C++ standard library, it's
not talking about "libraries" in the sense that you're talking about them.
>
> Of course, this is kept vague for flexibility, which makes sense. But
> given that libraries themselves are also often written in C and C++ themselves,
> it becomes messy when trying to export code from them for use in other
> executables, with chains of conditionals guarding macro definitions and
> so on.
>
> Currently, C++ only defines a program image in terms of an executable in the
> corresponding execution environment, so that the main function can be
> well defined within the language itself. Would it be possible to extend this
> definition slightly to include a very minimalistic definition of
> libraries in the language as well, alongside language features specific to
> libraries to export functions?
>
> """
> +++ Any executable program +++ shall contain a global function called
> main. Executing a program starts a main thread of execution (6.8.2, 33.3)
> in which the main function is invoked, and in which variables of static
> storage duration might be initialized (6.8.3.2) and destroyed (6.8.3.4).
> +++ It is implementation-defined whether an executable program in a
> freestanding environment is required to define a main function. Library
> programs cannot contain main functions. +++
> """
>
There are no "library programs". Libraries are fragments of a program, not
complete programs. Since you can't execute a library, the C++ standard
doesn't need to say anything about them. They're just a way of grouping
translation units together for inclusion in a complete program, and the
standard already talks about translation units and programs.
You say that the aim is to define mechanisms for controlling exports from
libraries, which might well be useful, but the change suggested above
doesn't give us that, and doesn't actually achieve anything. It seems like
a completely meaningless change (especially as you haven't added any
wording to define what "executable program" and "library program" actually
mean here).
The proposal
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0275r4.html has
links to past proposals related to shared libraries, you might find it
helpful to read those.
Received on 2023-04-03 13:44:14