On Monday, 23 January 2023 01:49:05 PST Edward Catmur wrote:
> > void f(I *ptr)
> > {
> > apply(ptr, ptr+1, [](auto p) { p->something(); });
> > }
>
> That only uses pointer arithmetic, not `sizeof`?

It's implicit there in the pointer math.

> > https://gitlab.com/thiagomacieira/qtbase/-/blob/master/src/corelib/tools/
> > qgenericarray.h#L310-313
> > <https://gitlab.com/thiagomacieira/qtbase/-/blob/master/src/corelib/tools/
> > qgenericarray.h#L310-313> (this code is not in production, it was a
> > prototype)
>
> You aren't going to be able to create a QGenericArray of abstract class
> `I`, though?

No, you wouldn't, but the fact that this is a generic array is not important.

> I feel like we should be moving away from 1-element array views now we have
> iterator-sentinel pairs (e.g. for std::views::single). I guess you might
> want to erase down to a pointer pair, though.

That code was a prototype from 2012 that still needed to support C++98. This
container didn't have emplacement functions. The full production version does,
so the trick wasn't necessary.

> Also, there's the possibility you might want to inspect the memory of an
> abstract base class, e.g. as_bytes(span(static_cast<I*>(&obj), 1)). You
> need either sizeof or pointer arithmetic to do that, so I don't think we
> can talk about making them ill-formed.

Yes, good point.

> Still, a warning flag would be good to experiment with: -Wabstract-sizeof,
> -Wabstract-pointer-arithmetic.

QoI.

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