This is something that needs to be done before FOUND is fit to be run on embedded systems. This is due to the heap inherently being non-deterministic in how much/what memory is available at a given point in time (due to issues like fragmentation with repeated allocations/frees). The solution to this is using the ETL library to replace STL containers and smart pointer implementations to be placed on the stack.
- Smart pointers are complicated here. What ETL does, is essentially make its own mini heap (called a pool) on the stack, that maintains the reference count (for shared ptrs) and ownership (for unique ptrs), where you provide it the number and the type of object you want to have for that pool.
- Another option for smart pointers could be using std::move on the object directly (by value), but I'm not a huge fan of this personally.
However, we should still maintain the ability to use the heap for convenience purposes for personal testing/usage. In addition, we don't (and shouldn't) need to override malloc/free implementations (namely for stb_image, since we just allocate a large buffer at the start of the program and then free it at the end, which is essentially deterministic). We are mainly concerned about allocating/deallocating objects, which is small allocations that happen frequently.
I believe this will mean we need two separate builds (one with heap and one without), and thus more options in build.sh and the github actions. And thus checking coverage on both separately. I think the toggle for ETL container builds should be done through a CMake option.
This is something that needs to be done before FOUND is fit to be run on embedded systems. This is due to the heap inherently being non-deterministic in how much/what memory is available at a given point in time (due to issues like fragmentation with repeated allocations/frees). The solution to this is using the ETL library to replace STL containers and smart pointer implementations to be placed on the stack.
However, we should still maintain the ability to use the heap for convenience purposes for personal testing/usage. In addition, we don't (and shouldn't) need to override malloc/free implementations (namely for stb_image, since we just allocate a large buffer at the start of the program and then free it at the end, which is essentially deterministic). We are mainly concerned about allocating/deallocating objects, which is small allocations that happen frequently.
I believe this will mean we need two separate builds (one with heap and one without), and thus more options in build.sh and the github actions. And thus checking coverage on both separately. I think the toggle for ETL container builds should be done through a CMake option.