>  EVERY C++ programmer must know about them

I disagree with this statement. I know many developers working with C++ for many many years who are working on the infrastructure that has been created and never had to deal with library/application/symbol visibility and so on.


On Mon, Jun 26, 2023 at 1:32 PM Thiago Macieira via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Sunday, 25 June 2023 21:30:18 PDT Julien Villemure-Fréchette via Std-
Proposals wrote:
> Now, in contrast, adding specification for translated translation units, or
> restricting, or prohibiting, or keeping status quo does not change behavior
> of conforming programs, and does not simply the mental model of the source
> code. In the opposite, now the specification will need to take into account
> entities other than TUs, that means a combinatorial number of clauses that
> mentions TU in the standard will need to be analysed to see how it can
> potentially interact with those new kinds of physical program fragments.
>
> So, what kind of problems are we interested in solving anyways with this?.

Start with the ability to export and import symbols to/from shared libraries /
DLLs. Like I said, there are two sets of well-known extensions and EVERY C++
programmer must know about them, whether they are creating a library or an
application. It's not an optional part of the C++ experience.

So it should be standardised.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering



--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals