Date: Mon, 13 Feb 2023 01:08:04 +0000
On Mon, Feb 13, 2023 at 12:39 AM Thiago Macieira wrote:
>
> Except that you forgot to take into account the complexity of the issue.
> You're asking for something that requires a field in the object in question.
We already do this. We already have language features in C++ that hide
extra data inside each object. If I change:
struct Monkey {
int i;
};
to:
struct Monkey {
int i;
virtual ~Monkey(void) {}
};
Then sizeof(Monkey) mysteriously gets bigger. It's because we're
hiding something in there.
If we can hide a pointer to a vtable then why can't we hide an
atomic_flag? I do realise though that 'Monkey' would no longer be
trivially-constructible, but you get that effect with adding a vtable
pointer too.
> Therefore, there must be a syntax that adds this member.
We don't have syntax for adding the vtable pointer.
> How is #3 different from #1?
It's not, but I like the verbosity of the syntax I proposed. At a
glance you can see if it's for "just this object" or "all objects".
>
> Except that you forgot to take into account the complexity of the issue.
> You're asking for something that requires a field in the object in question.
We already do this. We already have language features in C++ that hide
extra data inside each object. If I change:
struct Monkey {
int i;
};
to:
struct Monkey {
int i;
virtual ~Monkey(void) {}
};
Then sizeof(Monkey) mysteriously gets bigger. It's because we're
hiding something in there.
If we can hide a pointer to a vtable then why can't we hide an
atomic_flag? I do realise though that 'Monkey' would no longer be
trivially-constructible, but you get that effect with adding a vtable
pointer too.
> Therefore, there must be a syntax that adds this member.
We don't have syntax for adding the vtable pointer.
> How is #3 different from #1?
It's not, but I like the verbosity of the syntax I proposed. At a
glance you can see if it's for "just this object" or "all objects".
Received on 2023-02-13 01:08:14