On Sunday 7 April 2024 14:09:23 CDT Frederick Virchanza Gotham via Std-
Proposals wrote:
> On Sun, Apr 7, 2024 at 7:36 PM Thiago Macieira wrote:
> > > We need more information in std::type_info, such as the 'sizeof'
> >
> > We do? Why? What are the use-cases? Why can't they store that information
> > elsewhere? Why must everyone who uses typeinfo pay this extra payload
> > penalty?
> Well here's one use case in my paper on std::exception_typeid . . .

I don't see that as having the size or alignment of the exception type as a
required condition.

> Open the below HTML link and scroll down to "As a stepping stone":
>
> http://www.virjacode.com/papers/p3178.htm

That section starts with "There has been recent discussion about making major
additions to" but doesn't link to papers or committee minutes where said
discussion happened. Therefore, I am discounting it as "it never happened".

Logging an hexdump of an unknown type is unlikely to prove useful. For the
polymorphic ones, at least one sub-object will be a pointer to the vtable,
which isn't directly useful in an hexdump because of Address Space Layout
Randomisation that every single OS uses for security reasons. Any pointers to
heap area also pretty useless, unless they're chased and dumped too. Your best
hope is that there's a short string in that object that contains useful
information. Instead, anyone debugging would want something more powerful that
already exists: a core dump. So hex-dumping exceptions for me is a very weak
use-case, therefore I also fail to see the need for the size, let alone the
alignment of the object.

> There won't be an extra payload penalty if we first try to make an
> exhaustive list of what's /already/ available on Itanium ABI and
> Microsoft ABI.

This information isn't there. Since it isn't there, the information can't be
offered for code that is being compiled today.

In any case, you didn't answer my other question: why don't you extract this
information yourself? QMetaType does store the size and alignment of the type,
for example, plus a default constructor, copy constructor, destructor, etc.

> I think the right way of going about this is to make an exhaustive
> list for each ABI, and then to find the common subsection between the
> ABI's. Here's what I've got so far for the Itanium ABI:

Start with the use-cases first, not the solutions. You keep on having this
problem: you've got a solution and now you're looking for a problem to solve
with it. Stop doing that.

Moreover, once you come up with an implementation, you keep on insisting on
it, sometimes going to ever more ludicrous use-cases to justify it, instead of
finding other possible solutions to the same problem.

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