Forum Replies Created
-
Posts
-
I guess “they” (I believe your colleagues), are following a coding best practice that maybe someone (or some fantastic senior coders in your firm) suggested but no one kind of questioned them why. So, it’s like a directive that everyone follows.
Along with Rainer’s reason, maybe one or some or all of the following are the reasons:
- Encapsulation:
- managing uninitialized storage is encapsulated in a struct (construction, retrieval, and destruction).
- otherwise, multiple instances or different types would need repetitive boilerplate code.
- Type Safety:
- defined interfaces would be used for the all interactions in the well-designed wrapper
- avoids accidental misuse, wrong type access, no destruction etc.
- Value Semantics:
- Maybe there are future changes possible which would mean flexibility in adapting is needed (?)
- Reusability:
- duplicating code for type construction and destruction is avoidable
- Clarity and Maintainability:
- if there are operations to be performed, then interface methods make it more readable than reading raw operations code and C++ is generally hard to read, at least for me :)
I have been working on eBike-embedded-SW development at Bosch for the last 3 years. This is my first C++ professional project. In the past, I have worked in automotive, IoT, and Industrial automation domains, all in the capacity of embedded SW development but it has always been with C language.
At Bosch, we(my team and I) develop what we call Bike OS, which is, in other words, is a middleware layer that provides application developers with system level features and services. This makes things a bit more complex as you need heavily use templated code so that the app developers of the various ebike components can implement their flavour of those template classes.
Maybe I am specializing too much, but for general embedded domain applications, what would make more sense? For highly composite types, I think pass by value is a big ask both in terms of resources and execution time.
Some background: I have seen some embedded code, not too much, at work doing the exact same thing and as far as I know, we specifically do not guarantee that our sw is re-entrant. I don’t know if this is then just some flashy code or there is some more advantage of this
- Encapsulation:
