C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Chimeric Pointer

From: Smith, Jim <jim.smith_at_[hidden]>
Date: Mon, 28 Nov 2022 13:58:16 +0000
Hi All,

There's something similar to this idea that uses the virtual method table pointer.

For example, if this was polymorphism B would be derived from A and no casting would be needed:

class A {
public:
virtual void fooA() = 0;
};

class B {
virtual void fooB() { std::cerr << "I'm fooB " << std::endl; }
};

...

A *a;
B *b = new B;

void* ptr = reinterpret_cast<void*>(b);
a = reinterpret_cast<A*>(ptr);

a->fooA(); // prints 'I'm fooB'

delete b;

wrapping this technique in a template would make it look cleaner but, I don't see why you would want to use this technique or add the ability to the language.

-- James S
------- Original Message -------
On Sunday, November 27th, 2022 at 12:26 PM, Arthur O'Dwyer via Std-Proposals <std-proposals_at_[hidden]> wrote:

> On Sun, Nov 27, 2022 at 12:03 PM Phil Endecott via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>> I think it would be possible to implement operator->* to make this
>> possible:
>>
>> struct A { void fn_a(); };
>> struct B { void fn_b(); };
>> struct AB: A, B {};
>>
>> chimeric_ptr<A,B> p;
>> p ->* &A::fn_a ();
>>
>> That's fractionally less typing than p.as<A>()->fn_a(). Is it any
>> clearer? (Does it actually work - I've not tried to implement it!)
>
> No and no. Operator precedence requires parentheses there:
> (p->*&A::fn_a)();
> Also, by requiring `fn_a` to be an addressable entity, you're preventing it from being an overload set, or a template, or a static member function, or whatever.
>
>> I could imagine a core language change to make p -> A::fn_a equivalent
>> to p ->* &A::fn_a, i.e. allowing the "redundant" *& to be elided. Would
>> that conflict with other syntax?
>
> I cannot imagine such a core-language change. Notice that `p->A::fn_a()` is already valid C++ syntax.
>
> –Arthur

Received on 2022-11-28 13:58:30