On Fri, Nov 28, 2025 at 8:18 AM Ville Voutilainen wrote:
>
> Oh, standardization is very much engineering. But cobbling up a
> prototype implementation of what-ever and not documenting what the
> idea behind it is is not.


You flatter me, V Dogg. I'm busily writing the paper for
'chimeric_ptr' and will share it in a day or two or three. So far I've
written 5 alternatives into the paper along with sample code for each,
it's getting pretty beefy. And of course in the 'Acknowledgements',
I'll mention the copy-pasting from Arthur's blog post which has been
very helpful.

Just this evening though, as I was writing the paper, I thought of
another cool use for 'chimeric_ptr'. Let's say that you want all of
the benefits of inheritance, i.e. you want all of the base class's
member variables and member functions to be resolvable for an instance
of the derived class, but you don't actually want inheritance in its
fullness (perhaps because of conflicting member names -- e.g. if the
two base classes are from two different libraries).

The chimeric pointer will allow you to do the following:

    struct Processor {
        virtual void Process(void) = 0;
    };

    struct Editor {
        virtual void Edit(void) = 0;
    };

    void EditAndProcess( std::chimeric_ptr<Editor, Processor> const p )
    {
        p->Edit();
        p->Process();
    }

    struct Emulator : Editor {

        struct EmulatorProcessor : Processor {
            void Process(void) override { puts("EmulatorProcessor Process"); }
        };

        EmulatorProcessor proc;

        void Edit(void) override { puts("EmulatorProcessor Process"); }

        operator Processor&(void) noexcept { return proc; }
    };

    int main(void)
    {
        Emulator e;
        EditAndProcess(&e);
    }

Even though 'Emulator' is not derived from 'Processor', you can still
use the Processor interface on an Emulator object because there is an
implicit conversion from Emulator& to Processor&. The chimeric pointer
allows this.

In order to make this work, I need to edit the header file
"chimeric_ptr.h" in my compiler up on GodBolt, which I will do
tomorrow. For the time being though, the following GodBolt is tested
and working as I provide the implementation of 'chimeric_ptr' without
including the <memory> header:

    https://godbolt.org/z/369b5TzPf

I'm telling you all, this chimeric pointer will be the best new
feature since C++11, and I shall truly pay homage to my absorbed twin.