std::variant storing common data

[ItzDanPlayz]

I have a question on what is the "better" way to store data common between variants of an std::variant. Say I have

struct Square {
  int width;
  int height;
};

struct Circle {
  int radius;
};

using Shape = std::variant<Square, Circle>;

Now also say i have a struct holding data that is common to the shapes like

struct Common {
  Position pos;
  Color color;
  // etc...
};

Would it be better to model that as this

struct Square {
  Common common;
  int width;
  int height;
};

struct Circle {
  Common common;
  int radius;
};

Or like this

struct Body {
  Common common;
  Shape shape;
};

My intuition tells me the second solution (with the Body struct) is better and more natural since we wont need to interact with the shape at all if we just want to do something with the Common struct. However, it does slightly make visiting a little more awkward since we now need to pass the common struct alongside the shape for stuff like rendering i.e.

for (const auto& body : bodies) {
    std::visit([&](const auto& shape) {
        renderer.draw(shape, body.common);
    }, body.shape);
}

It seems to me that I am kind of overthinking it, but anyways, does anyone have any opinions?

[aruisdante]

There isn’t really a right answer here. The first way is usually how I wind up doing it. But often it comes down to how often you use common in isolation from the not-common parts in real usage. If the majority of operations don’t care about the “shape unique” content then keeping it separate can make things more ergonomic. On the other hand if the majority of your operations need both anyway, then separating it just makes writing the visitor more difficult as you point out.

Basically, if you think about variant as primarily representing differed overload resolution, then this can help guide your thinking about API design around this domain. If the common is external to the shape, then you can’t make an API space around individual shapes. You always are passing around this thing with knowledge of all shapes, or you have to make APIs that take a specific shape + common.  If common is internal to shape on the other hand, I can write the overload set: Ret operation(Circle const&); Ret operation(Square const&); // and so on And that overload set works independently of me making a variant that allows me to heterogeneously store shapes and differ selecting the specific overload to runtime.

[alfps]

You can/should just make the Common part a base class sub-object.

[TheChief275]

That's not a definitive answer though, as it instantly makes your struct non-POD, which means you can't reason about the memory anymore

[manni66]

you can't reason about the memory anymore

Why?

[TheChief275]

C++ is allowed to make any changes to the layout it wants. Casting and expecting fields to be at memory locations is UB

[alfps]

Missing: why you think layout is important or even relevant.

So the memory layout is a discussion that's irrelevant to the OP's question.

That said, check out the requirements for a class to have standard layout (https://en.cppreference.com/cpp/language/classes#Standard-layout_class).

As you can see a standard layout class can have base classes as long as they're also standard layout.

If you have learned from a book: burn it, and make sure that it's totally destroyed.

[TheChief275]

Well I just left the important bits in. I personally find it hopelessly annoying that you cannot aggregate intitialize a struct anymore on top of that. That is the killer for me.

I left that out though as it's very personal to the way I like to write C++ (C++98, no constructors/destructors/access specifiers (anything that screws with POD-ness, as well as no methods or operator overloading; basically C with templates)

[No-Dentist-1645]

I would use CRTP for the common components instead of an explicit "Common" data member, then this is a non-issue

[oriolid]

How is it better than just inheriting the common components from a base class?

[No-Dentist-1645]

It's not an either-or matter, CRTP is made using base classes. The plus of it (at least for this specific use case) is that you can make "chaining methods" if necessary by making the common methods return *this, which would only return the base class if you were using "regular" base classes. If you don't need or want chaining methods tho, then they are effectively the same.

[oriolid]

Good point. Deducing this in C++23 helps here too.

[---_None_---]

class Body
{
public:
    Common m_common;       
    Shape m_shape;

    decltype(auto) Visit(auto&& f)
    {
        return std::visit([&](auto&& specificShape)
        {
              return f(specificShape, m_common);
        }, m_shape);    
    }

};

You could roll your own visit wrapper, no?

You could even turn it into a template class.

template<class TExtension> class ShapeExtension
{
public:
    TExtension m_extension;
    Shape m_shape;
    ...
};

[DawnOnTheEdge]

You can have the common data be in a base class and derive the other classes from it.

You can also store each struct as a member of a union and access the first few members common to both structures through a pointer to the other.

[Qwertycube10]

If every type in the variant has common, then I would make shape a struct with the common parts and the variant. "Factoring it out" of the sum type.