RE: C++ and STL : write code that is not dependent on the container type

Jan Cumps — Tue, 13 Aug 2024 19:52:39 GMT

There's also another alternative:

Instead of accepting containers as auto, you can accept a std::span<of a particular type>

void print(std::span<std::string> range)

There are pros and cons

con:

it only accepts artifacts that have a continuous set of date. a std::array, a std::vector or a classic C type array. And views/ranges based upon those.
there is overhead (tiny though)

pro:

because you tell the span what data type is contained, your IDE and source insight/completion tools will work
you don't have to put the implementation in the header file. This may be a thing if you have IP in the implementation.
again, no data is copied. The original container is where the data sits.
I prefer auto a lot. But preferably defined close to where it is used. Except if the library I'm writing is truly generic.
In this case, I'm actually expecting an MNEO compatible reply. My lib is not that generic.
This is not a rule but a style choice.

The main difference is that it's known at writing time, what type of data is in your container.
With auto, that info is known at compile time. Still very good :), because you will not be able to write programs that violate compliancy in both cases.

I have a slight preference for the std::span in my Teseo library. Open for other positions.

RE: C++ and STL : write code that is not dependent on the container type

Jan Cumps — Mon, 12 Aug 2024 21:33:11 GMT

This post was a preparation for adding flex to the ST Teseo GPS driver that I'm desining.

I altered that library's code now to use auto: https://github.com/jancumps/gps_teseo_lib/pull/1/files. This does not cost anything at run time. No executable code is added or deleted.

What it allows you to do, is make different decisions when you are using the library on a microcontroller, or on a Linux / Windows device.

In some microcontroller designs, dynamic memory allocation is not allowed. For that reason, your architect may not allow you to use std::vector containers. Because they can be extended at runtime - and that may result in additional dynamic memory allocated. My library does not extend them - it has measures in place to never do that. But you know how a code review can go .
By using the auto structure, you can now also use std::array containers. They are fixed size and don't have dynamic behavior.

If you use this library on a Pi, BB or PC, you can use - and take advantage of - the more dynamic containers. The code will work for both. With similar performance.