On 12/07/2024 01:47, Marcin Jaczewski wrote:
> pt., 12 lip 2024 o 00:58 Henry Miller via Std-Proposals
> <std-proposals_at_[hidden]> napisał(a):
>>
>> There are many who have lost company politics and so cannot recompile their existing code. There is code from a third party where the code is owned and built by a third party and so every recompile will cost significant money (half of it paid to them, half in support costs getting the compiler to them - this second also implies significant opportunity cost lost because those people are not doing something else). There is even code where the source is lost and you can't rebuild it at any price. Unfortunately I don't see how this (or anything else) can address those problems.
>
> How exactly will a change in standard help here? most of this code
> could even be from C++98 and all ABI stable types will be in C++26.
> Not to mention that all these libs need to use these tools. otherwise
> even if C++ gives you these types, libraries will not be portable.

The intention is to phase the problem out in the future. It won't change
already existing libraries.

> I think lot better would be to have way to have both old and new types
> in same sources like:
>
> ```
> void foo(std::cxx98::string s, std::string& b)
> {
> b = s;
> }
> ```

The paper lists the downsides of using this mechanism:

- It does not solve the situation where a class is used as a member in
another class (because its name does not get mangled into the parent
class name, and thus it is unknown if that particular std::string is a
std::cxx98::string, or some other).

- It would require multiple copies of such classes to be maintained in
perpetuity, making it a maintenance hazard for standard library authors.

- It makes the incorrect assumption that the number of changes any given
class would require over its lifetime (perpetuity!) would be small. This
is highly unlikely to be true.

- It does not help with classes from another standard library, or that
were compiled with different compiler settings.

- It does not help with making C++ functions accessible to other languages.

- There is an underlying assumption that, although the initial
implementation in std:: was suboptimal, the next version in std2:: (or
the new epoch, or new version) will immediately be perfect. This is
extremely unlikely to be true: optimisation is an ongoing process, with
new improvements made every year.

- It forces synchronization of standard library work with committee
work. Optimisation should, fundamentally, be linked to compiler
releases, and not to Standard releases.


Hans Guijt