inherit from a POD struct

Question

I am trying to find the best design for several classes that store data. For all I know I could do something with inheritance:

struct Data
{
    int a;
    int b;
    int c;
};

struct DerivedData : public Data
{
    int d;
};

struct AnotherDerivedData : public Data
{
    int e;
};

Or with composition:

struct ComposedData
{
    Data data;
    int d;
};

struct AnotherComposedData
{
    Data data;
    int e;
};

I am leaning towards inheritance because there is a relationship between Data and DerivedData. But I was wondering if it was good design since there are absolutely no functions to be inherited ?

Moreover, Data should not be used on its own, so I was wondering if I could make it abstract and if it was worth it ? I've read that to do that, you should make a pure virtual destructor or preferably a protected constructor:

struct Data
{
    int a;
    int b;
    int c;

protected:
    Data() = default;
};

But what I don't like here is that it introduces a bit of complexity in an otherwise simple struct. It is not even a POD (if I understood what PODs are correctly).

Any advice on what would be the best implementation ? Are there any other ways to do it ?

Edit: I realize I was not clear enough about what is mainly bothering me: There is a "is-a" relationship between DerivedData and Data. But for some reason, I am feeling like inheritance is a bit "excessive" because there are no functions to be overriden (and even no function at all). But maybe this is a misconception on my part and that inheritance is totally appropriate here ?

Answer 1

API

AFAIU Data is supposed to be "private" for clients. However, the approach with composition makes them know about it - they type ComposedData{}.data.a instead of ComposedData{}.a for the inheritance case.

Safety and performance

Data should not be used on its own, so I was wondering if I could make it abstract and if it was worth it ? I've read that to do that, you should make a pure virtual destructor or preferably a protected constructor

Virtual destructors dispatch through a virtual table, in the described case it gives you nothing but overhead. To disallow using raw Data, instead just hide its destructor from non-derivers:

class Data {
protected: ~Data() = default;
public: int a, b, c;
};

struct ComposedData: public Data { int d; }; // has access to the protected ~Data()

int main() {
  Data raw; // doesn't compile: raw.~Data() is inaccessible
  ComposedData composed; // OK (~ComposedData() is public)
}

Moreover, protected destructors, unlike protected constructors, prevent mistakes like this one:

struct NonTrivialData: public Data { std::string non_trivial_dtor; };

std::unique_ptr<Data> type_erased{new NonTrivialData{1, 2, 3, "i won't be deallocated"}};
// ...because ~Data() knows nothing about NonTrivialData::non_trivial_dtor

(I didn't use the usual make_unique because it cannot perform aggregate initialization.)

A protected destructor disallows calling ~Data() from the outside => the code doesn't compile.

A virtual destructor dispatches ~Data() as ~NonTrivialData() at runtime => the destruction is done properly. However, as far as using raw Data isn't preferable, preventing the mistake at compile-time and introducing no virtual tables provide better semantics and performance.

Feeling right about it

for some reason, I am feeling like inheritance is a bit "excessive" because there are no functions to be overriden

That's OK. E.g. in some meta code it could even be reasonable to inherit from a class like

template<typename ValueType> struct AliasHelper {
  using value_type = ValueType;
  using reference = ValueType&;
  using pointer = ValueType*;
  using const_reference = ValueType const&;
  using const_pointer = ValueType const*;
};

class Foo: public AliasHelper<int> {};
class Bar: public AliasHelper<short> {};
class Baz: public AliasHelper<long> {};

which doesn't even have fields! However, it greatly reduces boilerplate.