> this type of code is still in enough active development they would adopt
new Standard Library solution (at the earliest in 2028).

My understanding from previous discussions is that the microscope compiler
the OP was using is still on C++03. The creators (Texas Instruments) are
unlikely to upgrade C++ standards, and likely cannot if CHAR_BIT=8.

https://lists.isocpp.org/std-proposals/2025/06/14306.php

On Thu, Nov 27, 2025, 1:28 p.m. Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thursday, 27 November 2025 03:46:05 Pacific Standard Time Frederick
> Virchanza Gotham via Std-Proposals wrote:
> > The most feature-rich microscope was the Pink microscope. The class
> > that managed it was defined something like:
> >
> > class Pink : public IMicroscope, public IUtility, public IDrift,
> > public IIllumination, public IStage, public IEscape, public
> > IObjective, public IDiagnostics, public IIris, public IPower, public
> > IAsyncControl, public ICommsHandler {
> > . . .
> > };
>
> I am calling this a poor API design. It might have been the height of
> propriety back in the 1990s when OOP and polymorphism was all the rage,
> but it
> isn't today. Therefore, I don't think a solution is applicable to new code.
>
> However, we are left with legacy. If you can show in your paper:
> a) this problem exists often enough;
> b) there is a Standard Library solution that would greatly alleviate the
> problem;
> c) this type of code is still in enough active development they would
> adopt
> new Standard Library solution (at the earliest in 2028).
>
> then it could be adopted into the Standard.
>
> Again, looking forward to the paper.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>