> 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_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>