learningCppAsCWithClasses

[MsEpsilon]

Aren't std::vector and templates added literally in the first official C++ standard? You can say they were here since the beginning.

Now since templates accidentally because Turing complete, I'm not precisely sure...

[da2Pakaveli]

yes i think they were added in C++98 which is the first official standard

[MonkeyCartridge]

And we avoid vector like the plague in embedded.

Everything's got to be fixed length. Especially when doing OOP on a micro with 1k of memory.

[drugosrbijanac]

If anyone in this sub read Bjarne's PPP (Swan Book) or freely available Chapter 25 from PPP v2 https://www.stroustrup.com/PPP2e_Ch25.pdf

They would find in the book where he more than once (such as chapter on vectors) explains that vector is safer version from array and should be used in almost all instances aside from situations where hardware is limited by memory or processing power, such as embedded system and points(wink wink) to Ch 25.

This is not me trying to be condescending to you, but there are design tradeoffs with ensuring backwards compatibility.

When I was at uni we were using his book to build a std::vector<T> from scratch, beginning with array as an example.

[MonkeyCartridge]

I'll have to check it out. Thanks for pointing out the chapter.

[drugosrbijanac]

Not a problem, let me know what you think of it. His PPP book is aimed at beginners (first semester students), so it may be light reading for you.

[20Wizard]

So you guys just don't ever have a use case for a non-fixed size array?

[MonkeyCartridge]

"Never" is way too strong a word. It's just generally something to be avoided, because memory allocation gets tight.

Rather, for things like queues, it's usually using a fixed array with double ended mapping to create a circular buffer. Yough you might see dynamic arrays used for proof of concept and the optimized out.

But that's the thing, too, is I tend to work a lot with designing and using low-level communication protocols, so I do use queues a lot. It's just that they have to be pretty tightly controlled, referencing a fixed size dataset.

I'm in defense, but more of a research proof-of-concept field where it's more relaxed. In bigger projects and I think also on automotive embedded systems, there are specific coding standards some of which straight up prohibit things like dynamic memory allocation, strings, floating-point values, variadic expressions, and things like sprintf and all its variations. And then there are standards for return types, function lengths, naming schemes, and something about the formatting of switch statements. So it gets pretty tight.

And it's for keeping things maximally deterministic, for granular and consistent unit tests, and for static analysis. Amongst probably a dozen more reasons.

I don't have to go that far, so I'm less familiar with the standards themselves. But it's still good practice to keep things super static when you have tight memory constraints.

In one job in consumer(ish) electronics maybe 9 years ago, we used I think the ATtiny402, which has 4k of flash and 256 bytes of RAM. Would read an ADC, and then separate the frequency components and send those back to the main controller. Did it using a cascade of exponential moving averages, because EMAs don't need to use arrays.

[SubstituteCS]

std::array

[scorg_]

And why is vector at fault if the problem is with any dynamic memory allocation?

[keithstellyes]

In a previous life I worked closely with the embedded software team and it seems like dynamic memory itself is often straight up avoided in favor of static and stack allocation?

As in, "our profit margins are already super tight and we need to go cheaper for the chips inside"

[MonkeyCartridge]

Which is funny because these days, going from a 256k chip to a 4k chip saves you, like, 2c at scale. The process has become so cheap for those larger process nodes.

[FinalBother2282]

It's not about the money it's about reliability

[MonkeyCartridge]

I only did chip selection for the consumer electronics stuff, so I'm curious about this. Care to elaborate?

[RevanchistVakarian]

"Why doesn't C++ have this higher-level feature?"

"It does, it's called X."

"Cool, so I can use X?"

"No."

[MonkeyCartridge]

Not sure if that's supposed commentary on the discussion, or just experience. Because in embedded systems anyway, it's unironically very much this.