C++ Logo

std-proposals

Advanced search

[std-proposals] Concept of Libraries in C and C++

From: Julian Waters <tanksherman27_at_[hidden]>
Date: Sun, 2 Apr 2023 22:52:01 +0800
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."

 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. +++
"""

Definitions involving libraries are deliberately left vague in this context,
since they take a lot of different forms on different platforms, such as
ELF, Mach-O, Portable Executables, and so on; All they are are C++ (and C
if we extend it to that) programs that export functions (and perhaps
variables?) other programs can call instead of executable code in this con
text, their format and how they export symbols is of no concern to us.
Exporting
is also vague in how it is done, only that their "visibility" (a concept
already in gcc and a similar concept with Microsoft's dllexport) is contained
within their own library image by default and is not exported externally
unless explicitly stated as such by the developer.

I can't think of how an export definition can be introduced into the
language, but perhaps this could use what is already there and be built off the
language linkage specifier syntax?

I don't know if this could be applied backwards to existing standards
(since technically the wording changes are actually pretty minimal), or if this
should be a new proposal for future Standards unfortunately

best regards,
Julian

Received on 2023-04-02 14:52:38