Thou shalt not inherit from std::vector

Question

Ok, this is really difficult to confess, but I do have a strong temptation at the moment to inherit from std::vector.

I need about 10 customized algorithms for vector and I want them to be directly members of the vector. But naturally I want also to have the rest of std::vector's interface. Well, my first idea, as a law-abiding citizen, was to have an std::vector member in MyVector class. But then I would have to manually reprovide all of the std::vector's interface. Too much to type. Next, I thought about private inheritance, so that instead of reproviding methods I would write a bunch of using std::vector::member's in the public section. This is tedious too actually.

And here I am, I really do think that I can simply inherit publicly from std::vector, but provide a warning in the documentation that this class should not be used polymorphically. I think most developers are competent enough to understand that this shouldn't be used polymorphically anyway.

Is my decision absolutely unjustifiable? If so, why? Can you provide an alternative which would have the additional members actually members but would not involve retyping all of vector's interface? I doubt it, but if you can, I'll just be happy.

Also, apart from the fact that some idiot can write something like

std::vector<int>* p  = new MyVector

is there any other realistic peril in using MyVector? By saying realistic I discard things like imagine a function which takes a pointer to vector ...

Well, I've stated my case. I have sinned. Now it's up to you to forgive me or not :)

Howerton

Re: std::vector<int>* p = new MyVector doesn't really work in the first place, because std::vector does not have a virtual destructor. There will most certainly be undefined behavior in the near future. – Latten

So, you basically asking if it's ok to violate a common rule based on the fact that you are just too lazy to re-implement the container's interface? Then no, it is not. See, you can have the best of both worlds if you swallow that bitter pill and do it properly. Don't be that guy. Write robust code. – Tensive

Why is passing a pointer to vector in a function param unrealistic? – Stealing

Why can't you/don't want to add the functionality you need with non-member functions? To me, that would be the safest thing to do in this scenario. – Approach

@Crashworks: Probably since nobody allocates vector's dynamically, no function that receives a pointer to one will try to delete it? Apart from that, the static type of the argument will be a vector, and that should be just fine. – Quartermaster

@Jim: std::vector's interface is quite huge, and when C++1x comes along, it will greatly expand. That's a lot to type and more to expand in a few years. I think this is a good reason to consider inheritance instead of containment - if one follow the premise that those functions should be members (which I doubt). The rule to not to derive from STL containers is that they aren't polymorphic. If you aren't using them that way, it doesn't apply. – Landis

The real meat of the question is in the one sentence: "I want them to be directly members of the vector". Nothing else in the question really matters. Why do you "want" this? What is the problem with just providing this functionality as non-members? – Valois

As I mentioned in a comment to Karl's answer, caching is hard to implement in non-members. – Falgoust

Sorry for my ignorance, but lots of the classes I write don't have virtual destructors, I inherit from them, but don't use them polymorphically. What is special with std containers and inheriting from them? – Aeriel

@rafak: Nothing's special about the standard containers in that respect. But it's suspect to publicly inherit from any class if you don't intend to use it polymorphically: if you're simply going to add convenience methods, it's better to write these as free functions, because then they can also be used with existing objects of the base type; if you're adding extra invariants, people prefer having D contain a B instead of inheriting from it to avoid the risk of "accidental polymorphism" (having a D object treated as a B and breaking those invariants), even though it's more work. – Region

I'm going to be blunt. Saying: "provide a warning in the documentation that this class should not be used polymorphically. I think most developers are competent enough to understand that this shouldn't be used polymorphically anyway" is really pie-in-the-sky wishful thinking. You'll create a fertile breeding ground for future problems by skimping on a few lines of code today. In the blink of an eye "other developers" will be ignoring the documentation and doing things they're "not supposed to". Don't forget you're also doing something you're "not supposed to". ;) – Violoncello

thou shall not misspell shall as shalt – Ostium

@JoshC: "Thou shalt" has always been more common than "thou shall", and it's also the version found in the King James Bible (which is generally what people are alluding to when they write "thou shalt not [...]"). What on Earth would lead you to call it a "misspelling"? – Warmth

Some of these arguments are based on other developers screwing up because they haven't understood your std::container-inherrited implementations properly... but if you are the sole developer and always expecting to be so, you can discount at least these arguments right? – Ecumenical

Answer 1

Actually, there is nothing wrong with public inheritance of std::vector. If you need this, just do that.

I would suggest doing that only if it is really necessary. Only if you can't do what you want with free functions (e.g. should keep some state).

The problem is that MyVector is a new entity. It means a new C++ developer should know what the hell it is before using it. What's the difference between std::vector and MyVector? Which one is better to use here and there? What if I need to move std::vector to MyVector? May I just use swap() or not?

Do not produce new entities just to make something to look better. These entities (especially, such common) aren't going to live in vacuum. They will live in mixed environment with constantly increased entropy.

Staciastacie

I love this answer. It gave me a profound new handle on C++ class design choices. – Tugboat

My only counterargument to this is that one must really know what he's doing to do this. For example, do not introduce additional data members into MyVector and then try to pass it in to functions that accept std::vector& or std::vector*. If there's any kind of copy assignment involved using std::vector* or std::vector&, we have slicing issues where the new data members of MyVector will not be copied. The same would be true of calling swap through a base pointer/reference. I tend to think any kind of inheritance hierarchy that risks object slicing is a bad one. – Ensample

std::vector's destructor is not virtual, therefore you should never inherit from it – Sy

@AndréFratelli Or at the very least, if you do inherit from it, you should do so as an internal class that other programmers can't use (and inadvertently use polymorphically) without mucking about in your source code, and make sure you either never use it polymorphically, never create a MyVector on the heap, or only use a function that explicitly takes a pointer or reference to a MyVector to delete it. That would be bad style, though, so one would need a very good reason to do it. – Ohl

Basically, coding styles generally exist for a reason. If one wants to go against the generally accecpted style in situations like this, one should: Have a very good reason for doing so, be entirely aware of the risks involved in doing so, make sure that all of their code takes these risks into account, and actively prevent others from using their code in a manner that doesn't take the risks into account. It's usually more trouble than it's worth, especially since it indirectly involves a lot more effort than just having a private std::vector and exposing its interface as needed. – Ohl

I created a class which publicly inherited std::vector for this reason: I had old code with a non-STL vector class, and I wanted to move to STL. I reimplemented the old class as a derived class of std::vector, allowing me to continue using the old function names (e.g., Count() rather than size()) in old code, while writing new code using the std::vector functions. I did not add any data members, therefore std::vector's destructor worked fine for objects created on the heap. – Vitrify

@graham if UB is fine, sure. – Diastyle

@andre you shall not allocate a std vector using new on the heap nor delete it via a raw pointer; you shall not use a unique ptr to a vector. Pointer-based ownership requires virtual dtors; other ownership semantics do not. – Diastyle

@Yakk-AdamNevraumont: I assume that by UB you mean undefined behaviour. There was none. – Vitrify

@GrahamAsher If you delete an object through a pointer to base, and the destructor is not virtual, your program is exhibiting undefined behavior. One possible result of undefined behavior is "it worked fine in my tests". Another is that it emails your grandmother your web browsing history. Both are compliant with the C++ standard. It changing from one to the other with point releases of compilers, OSs, or the phase of the moon is also compliant. – Diastyle

@Yakk-AdamNevraumont If you delete an object through a pointer to base and the destructor is not virtual but the derived class adds no new data members or behaviour that necessitates a different destructor, the behaviour is not undefined. The base class destructor is called, and works correctly. – Vitrify

@GrahamAsher No, whenever you delete any object through a pointer to base without a virtual destructor, that is undefined behavior under the standard. I understand what you think is happening; you just happen to be wrong. "the base class destructor is called, and it works" is one possible symptom (and the most common) of this undefined behavior, because that is the naive machine code that the compiler usually generates. This does not make it safe nor a great idea to do. – Diastyle

@GrahamAsher open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf [Delete] 8.5.2.5/3: "In a single-object delete expression, if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined". -- it isn't even undefined by omission. It is explicitly undefined behavior. The meaning of a C++ program is not defined by the assembly it produces. – Diastyle

@Yakk-AdamNevraumont The standard is either unclear, incomplete or wrong on this point. When the compiler generates destructor code via a pointer to base, in a class with a non-virtual destructor, it has access only to the base class destructor, and thus (in the special case of a derived class adding no data members and having an empty destructor of its own) has no information which it can use to create undefined or incorrect behaviour, or to call the wrong destructor code. It is guaranteed to call the base destructor, and (in this special case) that is the right thing to do. – Vitrify

@graham C++ is not defined by the assembly code it generates. The standard is clear, complete and by definition normative; it defines what is C++. If you want to change the standard, make a proposal. Until then, your code has behaviour explictly and clearly not defined by the standard. I get it. Thinking C++ is defined by the code it generates is a common error. But until you understand that fundamental mistake, you will continue to be screwed over and probably angry when ((int)(unsigned)(int)-1) >= 0 is optimized into true and a whole myriad of other things. Including this mistake. – Diastyle

If inheriting from std::vector is good enough for Bjarne Stroustrup, it's good enough for me. See JL Borges's comment here: cplusplus.com/forum/general/156923. He quotes Stroustrup's Tour of C++ (draft), section 4.4.1.2, in which he creates a range-checking vector class Vec which inherits publicly from std::vector. I similarly create a class which inherits from std::vector and adds no data members. – Vitrify

Answer 2

The whole STL was designed in such way that algorithms and containers are separate.

This led to a concept of different types of iterators: const iterators, random access iterators, etc.

Therefore I recommend you to accept this convention and design your algorithms in such way that they won't care about what is the container they're working on - and they would only require a specific type of iterator which they'd need to perform their operations.

Also, let me redirect you to some good remarks by Jeff Attwood.

Knowledgeable

Answer 3

The main reason for not inheriting from std::vector publicly is an absence of a virtual destructor that effectively prevents you from polymorphic use of descendants. In particular, you are not allowed to delete a std::vector<T>* that actually points at a derived object (even if the derived class adds no members), yet the compiler generally can't warn you about it.

Private inheritance is allowed under these conditions. I therefore recommend using private inheritance and forwarding required methods from the parent as shown below.

class AdVector: private std::vector<double>
{
    typedef double T;
    typedef std::vector<double> vector;
public:
    using vector::push_back;
    using vector::operator[];
    using vector::begin;
    using vector::end;
    AdVector operator*(const AdVector & ) const;
    AdVector operator+(const AdVector & ) const;
    AdVector();
    virtual ~AdVector();
};

You should first consider refactoring your algorithms to abstract the type of container they are operating on and leave them as free templated functions, as pointed out by majority of answerers. This is usually done by making an algorithm accept a pair of iterators instead of container as arguments.

Falgoust

IIUC, the absence of a virtual destructor is only a problem if the derived class allocates resources which must be freed upon destruction. (They wouldn't be freed in a polymorphic use case because a context unknowingly taking ownership of a derived object via pointer to base would only call the base destructor when it is time.) Similar issues arise from other overridden member functions, so care must be taken that the base ones are valid to call. But absent additional resources, are there any other reasons? – Calculous

vector's allocated storage is not the issue -- after all, vector's destructor would be called all right through a pointer to vector. It's just that the standard forbids deleteing free store objects through a base class expression. The reason is surely that the (de)allocation mechanism may try to infer the size of the memory chunk to free from delete's operand, for example when there are several allocation arenas for objects of certain sizes. This restriction does, afaics, not apply to normal destruction of objects with static or automatic storage duration. – Calculous

@DavisHerring I think we agree there :-). – Calculous

@DavisHerring Ah, I see, you refer to my first comment -- there was an IIUC in that comment, and it ended in a question; I saw later that indeed it is always forbidden. (Basilevs had made a general statement, "effectively prevents", and I wondered about the specific way in which it prevents.) So yes, we agree: UB. – Calculous

@Falgoust That must have been inadvertent. Fixed. – Islean

Answer 4

If you're considering this, you've clearly already slain the language pedants in your office. With them out of the way, why not just do

struct MyVector
{
   std::vector<Thingy> v;  // public!
   void func1( ... ) ; // and so on
}

That will sidestep all the possible blunders that might come out of accidentally upcasting your MyVector class, and you can still access all the vector ops just by adding a little .v .

Stealing

And exposing containers and algorithms? See Kos' answer above. – Hatfield

prefer composition over inheritance – Inelegance

Answer 5

What are you hoping to accomplish? Just providing some functionality?

The C++ idiomatic way to do this is to just write some free functions that implement the functionality. Chances are you don't really require a std::vector, specifically for the functionality you're implementing, which means you're actually losing out on reusability by trying to inherit from std::vector.

I would strongly advise you to look at the standard library and headers, and meditate on how they work.

Fulks

Oh, please, I know that, but in this particular case it would be VERY convenient that the new functionality be as members. – Howerton

I'm not convinced. Could you update with some of the proposed code to explain why? – Fulks

look, for example, apart from back() and front() I want also to provide middle(), and I don't want it to look like middle(v), but v.middle() – Howerton

@Armen: apart from the aesthetics, are there any good reasons? – Viewless

@Armen: Better aesthetics, and greater genericity, would be to provide free front and back functions too. :) (Also consider the example of free begin and end in C++0x and boost.) – Quartermaster

@UncleBens: Hmm... I really like your idea, you know? :) – Howerton

I still don't what's wrong with free functions. If you don't like the "aesthetics" of the STL, maybe C++ is wrong place for you, aesthetically. And adding some member functions won't fix it, as much other algorithms are still free functions. – Illustrative

@Armen: no, aesthetics are not a good reason. Code readability and consistency are good reasons. But it doesn't have to look "pretty". It just has to be clear and readable. And of course, aesthetics are subjective. Anyway, as suggested, a much better way to get a consistent syntax is to re-implement members (front(), back() and whatever else) as non-members. In my code I've defined free begin() and end() functions, partly for the more consistent syntax, and partly because then I can use them with arrays as well. – Valois

@snemarch: Seconded. aesthetics are not a good reason. Code should run well, not look pretty for programmers. – Pinprick

It is hard to cache a result of heavy operation in an external algorithm. Suppose you have to calculate a sum of all elements in the vector or to solve a polynomial equation with vector elements as coefficients. Those operations are heavy and laziness would be useful for them. But you can't introduce it without wrapping or inheriting from the container. – Falgoust

@Basilevs' comment is the first good reason I've ever heard for adding methods as opposed to free functions. – Region

@Basilevs: I had been almost convinced that external better than internal until I saw your comment. If one insists to have external generic function, then a caching policy & contract must be designed :) – Poncho

@Falgoust You can make your algorithm (function) data-oriented and take both container and cache as in/out arguments. That would even increase flexibility. (What if someone doesn't want cache? They can pass nullptr as cache, then. Or what if someone wants to store it separately from vector data? No problem, either.) – Lenee

@Lenee This also opens up the possibility of providing a default caching solution that is used unless the user explicitly specifies otherwise, similar to what the standard does for allocation with std::allocator. Doing so would allow the programmer to make a cache that performs optimally in most situations so that the user doesn't need to make their own, while also allowing them to use their own custom cache when it would be more efficient. – Ohl

@Valois I agree, readability and consistency are good reasons to have methods. So I think std::list should have operator [] as well. Also vec.contains(stuff) would be more readable than std::find(vec.begin() vec.end(), stuff) != vec.end() – Cogitate

Answer 6

I think very few rules should be followed blindly 100% of the time. It sounds like you've given it quite a lot of thought, and are convinced that this is the way to go. So -- unless someone comes up with good specific reasons not to do this -- I think you should go ahead with your plan.

Rugg

Your first sentence is true 100% of the time. :) – Jinny

Unfortunately, the second sentence isn't. He hasn't given it a lot of thought. Most of the question is irrelevant. The only part of it that shows his motivation is "I want them to be directly members of the vector". I want. No reason for why this is desirable. Which sounds like he has given it no thought at all. – Valois

Answer 7

There is no reason to inherit from std::vector unless one wants to make a class that works differently than std::vector, because it handles in its own way the hidden details of std::vector's definition, or unless one has ideological reasons to use the objects of such class in place of std::vector's ones. However, the creators of the standard on C++ did not provide std::vector with any interface (in the form of protected members) that such inherited class could take advantage of in order to improve the vector in a specific way. Indeed, they had no way to think of any specific aspect that might need extension or fine-tune additional implementation, so they did not need to think of providing any such interface for any purpose.

The reasons for the second option can be only ideological, because std::vectors are not polymorphic, and otherwise there is no difference whether you expose std::vector's public interface via public inheritance or via public membership. (Suppose you need to keep some state in your object so you cannot get away with free functions). On a less sound note and from the ideological point of view, it appears that std::vectors are a kind of "simple idea", so any complexity in the form of objects of different possible classes in their place ideologically makes no use.

Hedgehog

Great answer. Welcome to SO! – Howerton

Answer 8

In practical terms: If you do not have any data members in your derived class, you do not have any problems, not even in polymorphic usage. You only need a virtual destructor if the sizes of the base class and the derived class are different and/or you have virtual functions (which means a v-table).

BUT in theory: From [expr.delete] in the C++0x FCD: In the first alternative (delete object), if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined.

But you can derive privately from std::vector without problems. I have used the following pattern:

class PointVector : private std::vector<PointType>
{
    typedef std::vector<PointType> Vector;
    ...
    using Vector::at;
    using Vector::clear;
    using Vector::iterator;
    using Vector::const_iterator;
    using Vector::begin;
    using Vector::end;
    using Vector::cbegin;
    using Vector::cend;
    using Vector::crbegin;
    using Vector::crend;
    using Vector::empty;
    using Vector::size;
    using Vector::reserve;
    using Vector::operator[];
    using Vector::assign;
    using Vector::insert;
    using Vector::erase;
    using Vector::front;
    using Vector::back;
    using Vector::push_back;
    using Vector::pop_back;
    using Vector::resize;
    ...

Dryad

"You only need a virtual destructor if the sizes of the base class and the derived class are different nad/or you have virtual functions (which means a v-table)." This claim is practically correct, but not theoretically – Howerton

yep, in principle it is still undefined behavior. – Valois

If you claim that this is undefined behaviour I would like to see a proof (quotation from the standard). – Dryad

To be more specific: The defined behaviour is that the destructor of the derived class may not be called. As it has to be empty nothing undefined or bad happens. – Dryad

@hmuelner: Unfortunately, Armen and jalf are correct on this one. From [expr.delete] in the C++0x FCD: <quote> In the first alternative (delete object), if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined.</quote> – Preraphaelite

Which is funny, because I actually thought the behavior was dependent on the presence of a non-trivial destructor (specifically, that POD classes could be destroyed via a pointer-to-base). – Preraphaelite

Answer 9

If you follow good C++ style, the absence of virtual function is not the problem, but slicing (see https://mcmap.net/q/47156/-what-is-object-slicing)

Why is absence of virtual functions not the problem? Because a function should not try to delete any pointer it receives, since it does not have an ownership of it. Therefore, if following strict ownership policies, virtual destructors should not be needed. For example, this is always wrong (with or without virtual destructor):

void foo(SomeType* obj)
    {
    if(obj!=nullptr) //The function prototype only makes sense if parameter is optional
        {
        obj->doStuff();
        }
    delete obj;
    }

class SpecialSomeType:public SomeType
    {
    // whatever 
    };

int main()
    {
    SpecialSomeType obj;
    doStuff(&obj); //Will crash here. But caller does not know that
//  ...
    }

In contrast, this will always work (with or without virtual destructor):

void foo(SomeType* obj)
    {
    if(obj!=nullptr) //The function prototype only makes sense if parameter is optional
        {
        obj->doStuff();
        }
    }

class SpecialSomeType:public SomeType
    {
    // whatever 
    };

int main()
    {
    SpecialSomeType obj;
    doStuff(&obj);
//  The correct destructor *will* be called here.
    }

If the object is created by a factory, the factory should also return a pointer to a working deleter, which should be used instead of delete, since the factory may use its own heap. The caller can get it form of a share_ptr or unique_ptr. In short, do not delete anything you didn't get directly from new.

Oddson

Answer 10

Yes it's safe as long as you are careful not to do the things that are not safe... I don't think I've ever seen anyone use a vector with new so in practice you'll likely be fine. However, it's not the common idiom in c++....

Are you able to give more information on what the algorithms are?

Sometimes you end up going down one road with a design and then can't see the other paths you might have taken - the fact that you claim to need to vector with 10 new algorithms rings alarm bells for me - are there really 10 general purpose algorithms that a vector can implement, or are you trying to make an object that is both a general purpose vector AND which contains application specific functions?

I'm certainly not saying that you shouldn't do this, it's just that with the information you've given alarm bells are ringing which makes me think that maybe something is wrong with your abstractions and there is a better way to achieve what you want.

Souterrain

Answer 11

I also inherited from std::vector recently, and found it to be very useful and so far I haven't experienced any problems with it.

My class is a sparse matrix class, meaning that I need to store my matrix elements somewhere, namely in an std::vector. My reason for inheriting was that I was a bit too lazy to write interfaces to all the methods and also I am interfacing the class to Python via SWIG, where there is already good interface code for std::vector. I found it much easier to extend this interface code to my class rather than writing a new one from scratch.

The only problem I can see with the approach is not so much with the non-virtual destructor, but rather some other methods, which I would like to overload, such as push_back(), resize(), insert() etc. Private inheritance could indeed be a good option.

Thanks!

Upgrade

In my experience, the worst long-term damage is often caused by people who try something ill-advised, and "so far haven't experienced (read noticed) any problems with it". – Violoncello

Answer 12

This question is guaranteed to produce breathless pearl-clutching, but in fact there is no defensible reason for avoiding, or "unnecessarily multiplying entities" to avoid, derivation from a Standard container. The simplest, shortest possible expression is clearest, and best.

You do need to exercise all the usual care around any derived type, but there is nothing special about the case of a base from the Standard. Overriding a base member function could be tricky, but that would be unwise to do with any non-virtual base, so there is not much special here. If you were to add a data member, you would need to worry about slicing if the member had to be kept consistent with contents of the base, but again that is the same for any base.

The place where I have found deriving from a standard container particularly useful is to add a single constructor that does precisely the initialization needed, with no chance of confusion or hijacking by other constructors. (I'm looking at you, initialization_list constructors!) Then, you can freely use the resulting object, sliced -- pass it by reference to something expecting the base, move from it to an instance of the base, what have you. There are no edge cases to worry about, unless it would bother you to bind a template argument to the derived class.

A place where this technique will be immediately useful in C++20 is reservation. Where we might have written

  std::vector<T> names; names.reserve(1000);

we can say

  template<typename C> 
  struct reserve_in : C { 
    reserve_in(std::size_t n) { this->reserve(n); }
  };

and then have, even as class members,

  . . .
  reserve_in<std::vector<T>> taken_names{1000};  // 1
  std::vector<T> given_names{reserve_in<std::vector<T>>{1000}}; // 2
  . . .

(according to preference) and not need to write a constructor just to call reserve() on them.

(The reason that reserve_in, technically, needs to wait for C++20 is that prior Standards don't require the capacity of an empty vector to be preserved across moves. That is acknowledged as an oversight, and can reasonably be expected to be fixed as a defect in time for '20. We can also expect the fix to be, effectively, backdated to previous Standards, because all existing implementations actually do preserve capacity across moves; the Standards just haven't required it. The eager can safely jump the gun -- reserving is almost always just an optimization anyway.)

Some would argue that the case of reserve_in is better served by a free function template:

  template<typename C> 
  auto reserve_in(std::size_t n) { C c; c.reserve(n); return c; }

Such an alternative is certainly viable -- and could even, at times, be infinitesimally faster, because of *RVO. But the choice of derivation or free function should be made on its own merits, and not from baseless (heh!) superstition about deriving from Standard components. In the example use above, only the second form would work with the free function; although outside of class context it could be written a little more concisely:

  auto given_names{reserve_in<std::vector<T>>(1000)}; // 2

Selfsacrifice

Answer 13

Here, let me introduce 2 more ways to do want you want. One is another way to wrap std::vector, another is the way to inherit without giving users a chance to break anything:

1. Let me add another way of wrapping std::vector without writing a lot of function wrappers.

#include <utility> // For std:: forward
struct Derived: protected std::vector<T> {
    // Anything...
    using underlying_t = std::vector<T>;

    auto* get_underlying() noexcept
    {
        return static_cast<underlying_t*>(this);
    }
    auto* get_underlying() const noexcept
    {
        return static_cast<underlying_t*>(this);
    }

    template <class Ret, class ...Args>
    auto apply_to_underlying_class(Ret (*underlying_t::member_f)(Args...), Args &&...args)
    {
        return (get_underlying()->*member_f)(std::forward<Args>(args)...);
    }
};

2. Inheriting from std::span instead of std::vector and avoid the dtor problem.

Genuflect