Hi Jim,

I do not believe this is safe (meaning: it is often NOT working!).

reinterpret_cast does not adapt the address to the specific class. (And cannot do it, as void* has no class information).

The base class can start at a different address than the child class.

Otherwise multiple base classes would not work, when they would all get the same address.
 

-----Ursprüngliche Nachricht-----
Von: Smith, Jim via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Mo 28.11.2022 14:58
Betreff: Re: [std-proposals] Chimeric Pointer
An: std-proposals@lists.isocpp.org;
CC: Smith, Jim <jim.smith@oursmithfamilyonline.com>;

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@lists.isocpp.org> wrote:

On Sun, Nov 27, 2022 at 12:03 PM Phil Endecott via Std-Proposals <std-proposals@lists.isocpp.org> 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

-- 
 Std-Proposals mailing list
 Std-Proposals@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals