On Saturday, 26 August 2023 15:25:38 PDT Frederick Virchanza Gotham via Std-
Proposals wrote:
> Those two classes have the same 4 functions at the beginning of their
> Vtable and that's all that matters. The customer won't create an
> object of type 'IABCComHandler' nor 'IXYZComHandler', so it doesn't
> matter what their size and alignment is. So long as the customer only
> uses the 4 functions that both classes have in common and which are
> located at the start of the Vtable, it will work fine. It's tested and
> working.

The correct fix is then to have both of them to derive from a common base
class, which you can then cast either to. That solution would be correct and
work on any compiler, any architecture, any word or pointer size, whether
optimisations are turned on or not. That's quite different from:

> By the way you assume that the "+8" had something to do with the size
> of a pointer -- whereas it might be an array of 8 char's. I didn't
> bother checking because it doesn't matter.

It actually does matter. What's happening here is that you implemented a patch
job that seems to work but you don't know for sure because you don't know why
it works. It's fragile as hell and I surely hope you marked it as

 // ### HACK HACK HACK - Clean me up ASAP

Because you don't know why it worked, you don't know long it will keep on
working. You don't know what the boundary conditions of it working or failing
again are. And the only worse thing than failing spectacularly is failing
silently, where things appear to work, but are producing silent garbage and
that is being propagated out (note: dealing with Silent Data Errors is my
$DAYJOB).

And because you've sidestepped the rules of the language, you've removed any
and all safety checks that there could be. If someone goes and makes a
modification to the class layours, your code that appears to work may break
again, usually after deployment.

What you're asking for is a bit different. What you're asking for is basically
to have another language with another set of rules in the same C++ compiler
and same source code. I can see the benefits you're speaking of, but:
a) it doesn't fix your concrete problem that you used as example
b) I seriously doubt this idea will be entertained by the committee or the
  compiler vendors
c) there are already some workarounds to what you want, that are compiler-
  specific (build in -O0 or -Og)

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering