C or modernC++ for IoT?

Question

C++ / C#

I use OrangePi Zero for my devices with 256MB of RAM and a 4-core workstation The

question remains the same: What is better to use pure C or C ++ for IoT with shared_ptr, exceptions, Dependency injection, templates, wrappers for each C library, for which has no analogues C ++ (such as working with GPIO, LCD, etc.)?
Am I getting too much overhead using C++ with its modern features and exceptions and wrappers when getting the final code? At least the compilation time of the code on the pluses for these devices turns out to be many times longer than for pure Sei.
C++ bits (such as not using exceptions and shared_ptr) don't interest me here.

Answer 1

I don't think that the overhead from shared_ptrC++'s and 's is much more than the overhead from similar things in C. After all, "extractions" there can be partially imitated through setjmp/ longjmpand other charms, and "shared_ptr" can be configured with handles, making a structure for storing data, a pointer to a delimiter function, and atomic counters of strong and weak references, which will be handled through the corresponding functions from <stdatomic.h>.
Well, at the same time implement "weak_ptr" by analogy with the positive one, for the sake of completeness.
Why am I doing all this?
If you don't need a certain feature, just don't use it.
And this statement is true regardless of the chosen language.
If you do not need some part of the language - this is not a reason to abandon it completely. All C++ is 100%, in my opinion, not needed at all on any project :)
And of the features of modern C++ in embedded, most likely it will bring the greatest benefit constexpr. In combination with templates, it will help to put a lot of things into compile time - and, unlike recursive functionality that uses only templates, it will look readable. It is rather weak in C++11 constexpr, but starting with C++14, there is room for overclocking with it.
From data structures, look first at arrayand tuple. For security, and
can help . If there are polymorphic hierarchies in your code, thenenum classnullptr
overridewill make the code clearer and prevent unpleasant errors with hiding instead of redefining.
I recommend watching Jason Turner's lectures on YouTube - he had videos about the use of modern C ++ in embedded. It showed the generated assembler - there were no differences from the similar low-level sish code at all. But in the source code, type safety and extensibility, which are not always possible to achieve with one pure Cishka.
I think that with the release of new C++ standards and the appearance of their support in compilers, this language should gain more popularity in embedding.

Answer 2

So you talk as if C++ is 2 things: shared_ptr and exceptions :D
You vaguely understand, it seems, what their purpose is.
Actions and atomics in the pros have always been used. Simply, you need to understand what they are for you.
Exceptions, that's why they are exceptions that are used in exceptional situations. If you shove them everywhere and cannot live without them, then something is wrong with your application architecture. This time.
Two. Any eksepsheny, rtti, inheritance, scheduling, etc. in embed'e is a wild overhead. But at the same time, for some reason, many software companies, including Google, simply turn off support for exceptions and rtti in their projects. And on this "stub" everything works for some reason. In addition, the size of the imbed binary is quite important and not in last place. Having drunk exceptions and rtti, it is possible to throw out garbage very well.
shared_ptr is not a silver bullet. As fshp already said, they are used in, well, just a very limited number of cases. They, like exceptions, cannot be shoved anywhere. Watch Sean Parent speak, read his papers. A very intelligent man from Adobe, one of the chief engineers of Photoshop. He describes well there and shows with examples that shared_ptr is just a well-disguised global variable, in fact, and even with an overhead from atomics. And before you use it, think a hundred times why you need it here. In 99% of cases, you can do without it, just like without RTTI. At the same time, unique_ptr is a very convenient and useful thing.
Modern C++ offers you many C-ish ways to return a value instead of an exception. You can return the same tied tuple, optional, variant, any, error_condition, error_code. Although they themselves love to throw exceptions, the code is much cleaner and easier to debug and understand than a million nested exceptions with a wild hierarchy and overhead.
And what you should use pluses for is the power of algorithms, iterators, traits, lambdas, transfer semantics, convenient atomics where they are really needed. And, of course, the templates of the 17th standard can even cut the hell out of a bald man in the compile time.
If you are all of the above, using only shared_ptr and exceptions, then you do not need C ++.

Answer 3

What are you so clinging to shared_ptr?
If you look closely at your code, you may be surprised to find that 50% of the time you use smart pointers instead of explicit delete in the destructor. Where it is possible and necessary to initialize a class member on the stack, people shove a pointer to it, and allocate it on the heap.
Looking even deeper, the remaining 49% of the places in the code where you use shared_ptr actually require a reference to a constant.
Well, 1% of real need is a meager overhead.
And you somehow rush from one extreme to another. Why don't you consider Modern C?

Answer 4

What is better to use for IoT pure C or C ++ with shared_ptr, exceptions, Dependency injection, templates, wrappers for each C library for which there are no C ++ analogues (such as working with GPIO, LCD, etc.)?

Yes, anything, even python, as long as it is more convenient for you.
You are not writing for microcontrollers with their limited resources, but for an ordinary miniature computer, albeit with GPIO.

Answer 5

golang:3