C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Chimeric Pointer

From: Sebastian Wittmeier <wittmeier_at_[hidden]>
Date: Mon, 28 Nov 2022 15:17:01 +0100
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_at_[hidden]> Gesendet:Mo 28.11.2022 14:58 Betreff:Re: [std-proposals] Chimeric Pointer An:std-proposals_at_[hidden]; CC:Smith, Jim <jim.smith_at_[hidden]>; 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] <mailto: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 <http://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_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2022-11-28 14:17:04