Hi,

Sorry for the misconception, I am aware that libraries are not executable
programs on their own, I should have worded that better.

The reason is simple really: Libraries having a mechanism to specify
what they export would be rather useful when writing them in C or C++ code.
Currently there is no mechanism or definition about libraries when it
comes to C and C++ however, nor anything to control what they export at
runtime to a program that needs them when loaded (because obviously not
everything in them is visible to whatever loaded them), which then means
compiler extensions are required to do this instead, which becomes an
extremely messy collection of macros when it comes to crossplatform code
(think of the clashes between __declspec(dllexport) and __attribute__
visibility and so on). Although the linking model across these platforms
differ substantially, one thing they do carry in common is that there are
2 types of visibilities: private, or only available inside the library, and
public, meaning that function or data chunk is exported and placed into a
symbol table of the library artifact/whatever. Since this is one thing that
remains similar across pretty much every platform, I was wondering if
formal unified syntax could be introduced for this purpose, making it
easier to control what symbols are exported when writing cross-platform
libraries in C++ (and C)

best regards,
Julian

On Sun, Apr 2, 2023 at 11:04 PM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> On Sun, 2 Apr 2023 at 17: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."
> >
> > 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
> context, 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
>
> I'm not exactly sure of two things:
> 1) what are you trying to accomplish?
> 2) why?
>
> Libraries are not programs. They are merely binary artifacts that can
> be combined into a program, via a (dynamic) linker. They contain
> translation
> units, but no programs.
>