Date: Wed, 14 Sep 2022 18:55:38 -0400
On Wed, Sep 14, 2022 at 6:05 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Wed, Sep 14, 2022 at 8:27 PM Jason McKesson via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > On Wed, Sep 14, 2022 at 3:15 PM Lénárd Szolnoki via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
>
> > Well, there is a reason for this: it allows overloading `operator->`
> > to access it. By explicitly specifying a type, you can create a single
> > overload for that operator which returns a pointer to that specific
> > type. If the type has to be computed, that would cause a problem if
> > the `Ts` have multiple common bases.
>
>
> Exactly.
>
>
> > That having been said, I agree that a facade would be preferable, some
> > type that references the variant and applies a specific base class
> > test to them.
>
>
> Do you mean a class that inherits from std::variant, or do you mean a
> class that contains a member object which is an std::variant?
No, I mean:
```
void foo(std::variant<Ts...> &v)
{
auto bv = std::base_variant<base_class_name>(v);
bv->some_base_class_function();
}
```
`base_variant` returns an object which references the variant in
question, but by itself it is not a variant. Note that `base_variant`
is not itself a class, as CTAD doesn't allow partial specification of
template arguments. It's a function that returns the actual base-class
accessing type.
> > I agree that the motivation section needs to be beefed up with more
> > than what amounts to a declaration that people want to avoid dynamic
> > allocations. I mean sure, they want to do that, but why are they using
> > base class polymorphism? As you point out, having both a vtable
> > pointer and a type discriminator in the object's storage isn't helping
> > in RAM-limited systems.
>
>
> If both "JPEG_File" and "Bitmap_File" have 128 bytes worth of char
> array buffers inside them, then that adds up to 256 bytes for the two
> objects. It's better to have 128 bytes + 1 byte (index) + 4 bytes
> (vtable pointer) = 133 bytes (plus a couple of bytes more for the
> Vtables and possibly also 'typeinfo').
Why do you only consider a type that takes up the space of both? Why
not just the `variant`? That would be even smaller.
My question basically amounts to why you have a base class interface
*at all* instead of *only* using visitation via a `variant`.
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Wed, Sep 14, 2022 at 8:27 PM Jason McKesson via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > On Wed, Sep 14, 2022 at 3:15 PM Lénárd Szolnoki via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
>
> > Well, there is a reason for this: it allows overloading `operator->`
> > to access it. By explicitly specifying a type, you can create a single
> > overload for that operator which returns a pointer to that specific
> > type. If the type has to be computed, that would cause a problem if
> > the `Ts` have multiple common bases.
>
>
> Exactly.
>
>
> > That having been said, I agree that a facade would be preferable, some
> > type that references the variant and applies a specific base class
> > test to them.
>
>
> Do you mean a class that inherits from std::variant, or do you mean a
> class that contains a member object which is an std::variant?
No, I mean:
```
void foo(std::variant<Ts...> &v)
{
auto bv = std::base_variant<base_class_name>(v);
bv->some_base_class_function();
}
```
`base_variant` returns an object which references the variant in
question, but by itself it is not a variant. Note that `base_variant`
is not itself a class, as CTAD doesn't allow partial specification of
template arguments. It's a function that returns the actual base-class
accessing type.
> > I agree that the motivation section needs to be beefed up with more
> > than what amounts to a declaration that people want to avoid dynamic
> > allocations. I mean sure, they want to do that, but why are they using
> > base class polymorphism? As you point out, having both a vtable
> > pointer and a type discriminator in the object's storage isn't helping
> > in RAM-limited systems.
>
>
> If both "JPEG_File" and "Bitmap_File" have 128 bytes worth of char
> array buffers inside them, then that adds up to 256 bytes for the two
> objects. It's better to have 128 bytes + 1 byte (index) + 4 bytes
> (vtable pointer) = 133 bytes (plus a couple of bytes more for the
> Vtables and possibly also 'typeinfo').
Why do you only consider a type that takes up the space of both? Why
not just the `variant`? That would be even smaller.
My question basically amounts to why you have a base class interface
*at all* instead of *only* using visitation via a `variant`.
Received on 2022-09-14 22:56:32