Background

For an embedded project, I want a class that takes a list of structs. This list is known at compile-time, so I shouldn't have to resort to dynamic memory allocation for this.

However, how do I make a struct/class that encapsulates this array without having to use its size as a template parameter?

Templates

My first idea was to do exactly that:

struct Point {
    const uint16_t a;
    const double b;
};

template<size_t n>
struct Profile {
    Array<Point, n> points;

    Profile(const Array<Point, n> &points) : points(points) {}
};

Here, Profile is the class that stores/encapsulates the array of points (the 2-member structs). n, the size of the array, is a template parameter.

I'm using this implementation of Array, similar to std::array, btw, because I don't have access to the STL on this embedded platform.

However, no I have another class that uses this Profile that now also has to be templated because Profile is templated with the size of the array:

template<size_t n>
class Runner {
private:
    const Profile<n> profile;
public:
    Runner(const Profile<n> &profile) : profile(profile) {};

    void foo() {
        for(auto point : profile.points) {
            // do something
        }
    }
};

As can be seen, this Runner class operates on a Profile and iterates over it. Having to template Runner is not that much of an issue by itself, but this Runner in turn is used by another class in my project, because this other class calls Runner::foo(). Now I have to template that class as well! And classes that use that class, etc.

That's getting out of hand! What started with just one template parameter to specify the size, now propagates through my entire application. Therefore, I don't think this is a good solution.

Question

Is there a way to 'hide' the size of the array in Profile or Runner? Runner only needs to iterate over it, so the size should in principle only affect its implementation, not its public interface. How would I do that, though?

Also, can I avoid having to manually specify n at all, and just pass an array to Profile's constructor and let the compiler figure out how big it is? At compile-time, of course. I feel like this should be possible (given this array is known at compile-time), but I don't know how exactly.

Other approaches

Macros

I could write a macro like

#define n 12

and include that in both the Profile.h and the place where I instantiate a Profile. This feels dirty though, I and would like to avoid macros.

Vector

I could avoid this fuss by just using a std::vector (or equivalent) instead, but that is allocated at run-time on the heap, which I would like to avoid here since it shouldn't be necessary.

CodePudding user response：

Is there a way to 'hide' the size of the array in Profile or Runner?

Yes. The solution is indirection. Instead of storing the object directly, you can point to it. You don't need to know the size of what you're pointing at.

A convenient solution is to point into dynamic storage (for example std::vector) because it allows you to "bind" the lifetime of the dynamically sized object to a member. That's not necessary in general, and you can use automatic storage instead. However, in that case you cannot bind the lifetime of the pointed object, and you must be very careful to not let the pointed object be destroyed before you stop using it.

The indirection can be done at whatever level you prefer. If you do it at the lowest level, you simply store the array outside of Profile. In fact, if all that profile does is contain an array, then you don't need a class for it. Use a generic span:

struct Runner {
    span<const Point> profile;
    void foo() {
        for(auto point : profile) {
            // do something
        }
    }
};

Point points[] {
    // ... number of points doesn't matter
};
Runner runner {
    .profile = points,
};

By span, I mean something like std::span. If you cannot use the standard library, then use another implementation. It's basically just a pointer and size, with convenient template constructor.

To clarify, you can pick any two, but you cannot have all three of these:

1. Lifetime of the array bound to the class (safe)
2. No compiletime constant size
3. No dynamic storage

• 1,2 (no 3) = std::vector, RAII
• 1,3 (no 2) = std::array, templates, no indirection
• 2,3 (no 1) = std::span, be careful with lifetimes

CodePudding user response：

I'll expand on this comment:

The idea is that Runner takes Profiles no matter their size. Runner needs to iterate over it, but apart from that, its behaviour is always the same. The class using Runner and calling Runner::foo() doesn't need to know the size. The problem with templating Runner is that the class using Runner also needs to be templated, and the classes using that, etc.

This is only a problem when the class is using the templated Runner directly. It has more dependencies than it actually needs. If it doesn't need to know about the size of the array, then it should not know about the size of the array. If runtime polymorphism is an option you can add a base class that allows accessing the array elements, but doesn't need to know anything about the arrays size. The following is only a sketch:

#include <iostream>

struct RunnerInterface {
    virtual int* begin() = 0;
    virtual int* end() = 0;
    virtual ~RunnerInterface(){}
};

template <unsigned size>
struct Runner : RunnerInterface {
    int data[size];
    int* begin() override { return data; }
    int* end() override { return data size; } // pointer one past the end if fine (it won't get dereferenced)
};

void foo(RunnerInterface& ri) {
    for (auto it = ri.begin(); it != ri.end();   it){
        *it = 42;
    }
}

void bar(RunnerInterface& ri){
    for (auto it = ri.begin(); it != ri.end();   it){
        std::cout << *it;
    }
}

int main() {
    Runner<42> r;
    foo(r);
    bar(r);
}

Now if a class needs a Runner member, they store a std::unique_ptr<RunnerInterface> and only on construction you need to decide for the size of the array (though you still need to decide for the size somewhere).