|
Who needs inheritance in embedded world?
Behzad
|
|
|
|
|
Why wouldn't you use inheritance? Do design patterns really change that significantly in embedded code?
Real programmers use butterflies
|
|
|
|
|
This is absolutely what I do. And I agree with you that so long as you understand and are happy with the 'hidden' code that C++ abstractions introduce, there's nothing wrong with using them.
The only time I'll use C rather than C++ is if I'm targeting a platform that doesn't have a C++ compiler. And yes, I have one of those - it's a proprietary processor, has a port of GCC, Gnat (the GCC Ada compiler) but not G++. Yes, it's for a safety critical application. No, I can't talk any more about it.
C++17 and 20 have introduced some nice new little abstractions, like std::string_view and std::span that would be useful in a C-ish world - basically, they're just pointer and length in a struct...
Also - things like lambdas, once you realise they're just a function pointer (if you have no captures) or a function object, are equally usable in a resource constrained environment.
The main thing I'd be wary of would be over many templates, in case they introduce too much code with multiple instantiations of functions for different template parameters.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
modified 3-Mar-21 6:08am.
|
|
|
|
|
I didn't know lambdas reduce to a function pointer without captures. I thought they were always functors. Cool.
On that subject, how would you go about accepting a lambda as a parameter to a function without accepting std::function? (i'm pretty sure you'd need to make the accepting function a template but it would be cool if you didn't)
For the most part, in embedded code I limit my templates to things that basically replace preprocessor macros, like
#define BAR_STATIC_ALLOCATION_SIZE 256
struct bar {
char foo[BAR_STATIC_ALLOCATION_SIZE];
};
instead i might make a declaration that allows for the following
bar<256> b;
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: On that subject, how would you go about accepting a lambda as a parameter to a function without accepting std::function? (i'm pretty sure you'd need to make the accepting function a template but it would be cool if you didn't)
The way I generally do it on a non-constrained platform is with a template:
template<class F>
int do_something(F&& f, int value)
{
return f(value);
}
However - there is a C++ standard proposal paper for something called a function_view , which is intended as a lightweight alternative to std::function purely for passing functions as parameters. This blog article explains it more. I've seen other std:function alternatives as well - this one, here on CodeProject was one of the first I saw, IIRC.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
unfortunately I'll probably be at least well on my way to dead by the time function_view makes its way through the standards body to find itself in C++50 and then finally gets picked up by GCC and then the Espressif ESP32 toolchain.
Real programmers use butterflies
|
|
|
|
|
All the code for it is contained in a single C++ header file - you could just incorporate that into your build
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
decltype(auto) operator()(TArgs... xs) const
Doesn't seem to matter how much time I spend looking at C++ code, I'm still always learning new things about it.
Didn't know decltype(auto) was a thing. That's pure magic. Now I know how they do their elastic functors.
Real programmers use butterflies
|
|
|
|
|
There's more than one way to skin that cat decltype(auto) is used instead of auto here because auto strips references from the type of the thing it's inferring from (e.g. if your function returned a std::string const& , using auto would cause it to return by value, whereas decltype(auto) would cause it to return the reference). However, in this case, auto&& has the same semantics as decltype(auto) , and will return by reference if that's what's wanted.
auto return types are useful for places where the return type is difficult (or impossible) to state statically - consider this code (which is valid c++17), which returns a string if it's instantiated for std::string and an integer otherwise... There are situations where something like this is useful.
template <class T>
auto foo(T const& t) {
if constexpr (std::is_same_v<T, std::string>) {
return "Hello";
} else {
return 3;
}
}
int main() {
std::cout << foo(12) << std::endl;
std::cout << foo(std::string("a")) << std::endl;
}
outputs
3
Hello
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I had no idea you could declare auto as a return value in some cases. I've only recently taken to using lambdas in C++ so that's probably part of it. I spent a long time away from C++ and am still catching up with C++ standards. So much has changed.
Real programmers use butterflies
|
|
|
|
|
I think the reason many embedded programmers prefer C to C++ lies in simplicity. If they are programming in C, they don't have to keep in mind nearly as many of the implications of how they are writing their code. It's an example of WYSIWYG. C++ provides far too many mechanisms like inheritance and overloading that impact performance and memory usage.
There's also a certain inertia in the embedded software industry. I remember when C was viewed with skepticism, while it is now a mainstay. It will take a significant number of C++ adepts moving into embedded programming before the language becomes significant. It will also need for some members of the C community to leave. People like Linus Torvalds, who makes blanket statements about defects in C++ as a language that are inherent in his mono-focus on the Linux kernel.
Software Zen: delete this;
|
|
|
|
|
I use C heavily, because it's easier to write cross-platform, cross-compiler code.
In particular, the ABI doesn't change between different (minor!) versions of the compiler.
For performance, C tends to be simpler code for sharp new algorithms.
That's particularly true for data-oriented designs and flow-based programming.
Also for libraries that other (C++) systems depend on.
There are C conventions that make "subclassing" easier. FWIW C99 made that simpler.
Opinion:
I'm tired of C++ trying to fix last version's problems with yet another complicated construct,
(auto_ptr? smart_ptr? unique_ptr? ...) requiring code restructuring in ways that other teams may have problems grokking. C++ seems to prefer hiding things, or at least slapping another coat of paint on them. Like getting from point A to point B via a Hilbert curve.
|
|
|
|
|
I do share your frustration with C++'s very much designed-by-committee** runtimes
** not that other languages aren't driven by standards bodies, but C++ very much "feels" like it is. Plowing through the STL standards is like trying to do pretty much anything at the DMV (at least in the states)
I can't find anything to argue about with your post in fact.
Real programmers use butterflies
|
|
|
|
|
I can't really advise you to use one over the other (as it's your personal preference), but I can tell you that I generally avoid doing C++ code over C for my own stuff.
Why? Perhaps I've been burned/annoyed by C++ too much over the decades (some of which may not be relevant anymore, but still has left a bitter taste)..
[rant-begin]
-- Mangling inconsistencies between compilers.
-- No unified naming conventions. Camel Case vs Pascal Case vs Snake Case.
-- Too much hungarian notation crap seen.
-- Headers with .hpp extension vs just .h (or worse, "standard" headers with no extension, causing pointless dummy files that include the real .h file in some implementations).
-- Overloading abused to non-intuitive things way too often.
-- Bloated / over-complex standard libraries.
-- The "new" C++ really should have been called something other than C++, since it has radically changed from early C++.
-- A bunch of translating back and forth needed when dealing with C APIs (most often C strings), which adds extra overhead.
-- .cpp files extensions. Always makes me think "C Pre-Processor", which predated C++. I mean, what where they thinking?! Though, .hpp files annoy me more. I use .cc when I must do C++ for my own projects.
-- Wrapping everything in "new" C++ (for memory/cleanup safety). Sure, it helps, but at what cost of hidden overhead, and is still no substitute for avoiding sloppy/undisciplined coding.
-- Bloated / over-complex standard libraries.. "I know that, technically, that’s only one drawback, but it was such a big one I thought I’d mention it twice." --Kryten/Red Dwarf
[rant-end]
In some cases I will still write a C++ wrapper for my C code, if it's a library, just for people who prefer using an OO API.
Now don't get me wrong.. some of the features of C++ are nice (like function grouping, protected methods, polymorphism), but often not worth the price of all the negatives.
|
|
|
|
|
The man at the door said I could get a good argument here!
veni bibi saltavi
|
|
|
|
|
To the soapb... oh.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
I'm sorry, but I'm not allowed to argue unless you've paid.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I paid the gentleman in the pink tutu at the door.
veni bibi saltavi
|
|
|
|
|
If you want me to go on arguing, you'll have to pay for another five minutes.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
You're not Eric are you? I was told to ask for Eric.
veni bibi saltavi
|
|
|
|
|
No, he's an Idle
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Aside from everything else, being a comparative newcomer to this place (and seeing no other place around this place, this must be the place) - I have to ask. Which of the two in your picture is supposed to be you?
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Which one was the Alien, and which the Predator?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I cautiously avoided asking if they were parental in nature. Now without a bottle of Gin in tow (and never put toe in Gin). After all, I don't know the guy as well as some of you beyond his poor taste in liquor.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I dunno, Gin can be rather pleasant, especially if you pour an unopened bottle of Vermouth into the glass.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|