Date: Thu, 4 Jul 2024 12:34:23 -0700
Funny that you should be asking about that now. At this very moment I am
writing a talk I will be giving at a couple conferences this fall, that
includes this exact subject.
The sidecast offset is specifically needed with multiple inheritance
because all the bases (except the first base) are NOT at the same "this"
address as the derived class. So when you cast from the derived to one of
the bases the pointer returned points specifically at the base object
address. If you change the type but not the address you will be pointing
at the wrong location (address of the first base class) using the wrong
type (but not the type of the first base class). The cast computes the
offset itself, however when you call via the virtual mechanism, the v-table
points to a multiple inheritance thunking function that adjusts the "this"
pointer address before calling the actual function to the start address of
the base object.
https://godbolt.org/z/sPTxe3sYP (mostly 64-bit)
https://tinyurl.com/sizecastpdf (slideware presumes 32bit)
Chris++;
On Thu, Jul 4, 2024 at 10:53 AM Phil Endecott via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Dear Experts,
>
> dynamic_cast will both downcast and sidecast. (And upcast, etc.)
>
> Is there some trick that can be used to constrain it to do one but not
> the other?
> If not, should the language provide additional casts that are more
> constrained
> in what they do? (I.e. downcast<T>(expr), upcast<T>(expr),
> sidecast<T>(expr).)
> Would that be feasible with how the current ABIs work?
>
> I ask because, as you can guess, I've just hit an issue where I was getting
> unexpected sidecasting where code was only expecting downcasting. My
> most derived class has multiple inheritance (but not virtual
> inheritance). I
> invoke some function on one of its base classes, and that unexpectedly
> behaves differently because it can cast itself to a sibling base class.
>
> Thoughts anyone?
>
>
> Regards, Phil.
>
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
writing a talk I will be giving at a couple conferences this fall, that
includes this exact subject.
The sidecast offset is specifically needed with multiple inheritance
because all the bases (except the first base) are NOT at the same "this"
address as the derived class. So when you cast from the derived to one of
the bases the pointer returned points specifically at the base object
address. If you change the type but not the address you will be pointing
at the wrong location (address of the first base class) using the wrong
type (but not the type of the first base class). The cast computes the
offset itself, however when you call via the virtual mechanism, the v-table
points to a multiple inheritance thunking function that adjusts the "this"
pointer address before calling the actual function to the start address of
the base object.
https://godbolt.org/z/sPTxe3sYP (mostly 64-bit)
https://tinyurl.com/sizecastpdf (slideware presumes 32bit)
Chris++;
On Thu, Jul 4, 2024 at 10:53 AM Phil Endecott via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Dear Experts,
>
> dynamic_cast will both downcast and sidecast. (And upcast, etc.)
>
> Is there some trick that can be used to constrain it to do one but not
> the other?
> If not, should the language provide additional casts that are more
> constrained
> in what they do? (I.e. downcast<T>(expr), upcast<T>(expr),
> sidecast<T>(expr).)
> Would that be feasible with how the current ABIs work?
>
> I ask because, as you can guess, I've just hit an issue where I was getting
> unexpected sidecasting where code was only expecting downcasting. My
> most derived class has multiple inheritance (but not virtual
> inheritance). I
> invoke some function on one of its base classes, and that unexpectedly
> behaves differently because it can cast itself to a sibling base class.
>
> Thoughts anyone?
>
>
> Regards, Phil.
>
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2024-07-04 19:34:39