New code in C? Where and why, versus C++?
-
This is something I'm really curious about, and maybe it's just because I'm newish to coding small gadgets, though most of it is comfortable to me since I cut my teeth on 6502 CPUs back in the day. What is the purpose of writing new code in C for targeting, well ... anything? I've put away my C compiler and simply relied on limited use of C++ features to keep the footprint the same as it is in C: 1. no vtables. slightly complicates inheritance, as you can no longer do virtual ~foo() {} 2. extremely limited use of the STL, if at all. I typically use std::atomic if available, but not std::string, for example 3. judicious use of extern "C" when exporting my main, or importing "C" headers 4. no exceptions/SEH/etc, RTTI or other C++ frills that bloat code or stack Why do I do it? Primarily for that sweet sweet RAII, but also general source management. Classes can keep everything together. HPP based libraries are useful for simplifying distribution. public and private members replace the need for hiding in C files in many cases. and many other reasons. Should I not be doing it? Is there a reason this is bad form? Is there a reason you wouldn't?
Real programmers use butterflies
i would use C as a personal preference. it's subjective. also i rather be in company of C programmers than C++, that is also one reason you would use a particular language. but, i assume you posted a question to get some objective info as why C is a better choice than C++ in your use case scenario. maybe it is not. C++ was designed by Bjarne with zero cost abstractions in mind - "What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better." lots of people in the game making business use C style code with the C++ compiler or as little as possible classes, shallow hierarchies and such. the C++ compiler is a powerful beast and we (the programmers) are in the business of automation. so in that sense it's a better choice. C++ does not force you to use it in any way, that's good. i think Bjarne was hot on the OOP subject, if you read early editions of the book, but not so any more. he merely says C++ gives you complete support for OOP if you want it, among other things. here is a statement from Bjarne's book that you may consider when programming embedded - "Except for the new, delete, typeid, dynamic_cast, throw operators and the try block, individual C++ expressions and statements need no run-time support." for myself, i don't dislike OOP as a technical solution and capability. i dislike object orientation in people. that philosophy, look everything is an "object" and everything is related in hierarchies, took a wrong turn. instead of a solution for a problem it became a problem of it's own and a philosophy of life. solving the problem of say input data > processing > output data with classes and objects (if you like) became looking at classes as something that has a life of it's own. carried away by work on the class rather then on the whole... you know what i mean, that thing: this is a car and a car is a vehicle. then in the boom of OOP it became, either you do it our way or the highway.
-
Maybe I just vastly misunderstand C++, but AFAIK you don't have to use ctors, which are basically "operator overloads" in a sense for object "creation/instantiation/initatialization". If they don't do anything the compiler doesn't generate code for them. And addressof & does the same thing in C as it does in C++, unless you overload it. The theme here is, if you don't use the feature, it doesn't produce the code to run the feature. So if anything it seems a matter of education? Knowing what C++ will generate and what it won't. I write code for real time devices in C++ all the time. There's no more latency than C. Consider the following:
class A {
public:
int x;
};This generates the same exact code as
struct A {
int x;
};There are no constructors there. x will not get initialized on instantiation because I didn't write code for it. They are also both sizeof(int) in size. If i needed initialization
class A {
public:
int x;
A() : x(0) {}
// i'm omitting the big-5 here
};this is no different than if i needed initialization in C except it's cleaner:
struct A {
int x;
};
void initializeA(struct A *a) {
// can't remember if -> is strictly C++ or not
(*a).x=0;
}The former doesn't pollute the namespace, and also prevents the case of forgetting to call the initialization function.
Real programmers use butterflies
honey the codewitch wrote:
So if anything it seems a matter of education? Knowing what C++ will generate and what it won't.
Perhaps this is the biggest issue. The level of knowledge one has to earn to know how to make the compiler generate what they want and even more importantly, know what the compiler will generate when reading someone else's code. This knowledge has a cost (potentially a high cost) that needs to be maintained by the organization through the expense of time and paid experience of every developer reading or maintaining the code. That expense must be offset by the reduction in cost of using C++ features that eliminate writing boilerplate code and organizing code. I suspect with the far simpler rules/capabilities of C code, you have to look at a lot less code you didn't write to understand exactly what it is doing without resorting to using a debugger or looking at assembly. My current opinion is that the decision of C versus C++ would come down to the project size and the pool and expense of developers you want maintaining the code. Imagine a "C++ developer" jumping into a project that required diagnosing a set of code that used partial and full template specialization a few levels deep and being asked to refactor it. Could they do it? The statements "I know C++" and "I know C" carry two different levels of trust. I would trust most people who claim to know C and I can easily test their knowledge. With C++, the question for me becomes, what parts of C++ do you know and how well do you know each?
Dave B
-
This is something I'm really curious about, and maybe it's just because I'm newish to coding small gadgets, though most of it is comfortable to me since I cut my teeth on 6502 CPUs back in the day. What is the purpose of writing new code in C for targeting, well ... anything? I've put away my C compiler and simply relied on limited use of C++ features to keep the footprint the same as it is in C: 1. no vtables. slightly complicates inheritance, as you can no longer do virtual ~foo() {} 2. extremely limited use of the STL, if at all. I typically use std::atomic if available, but not std::string, for example 3. judicious use of extern "C" when exporting my main, or importing "C" headers 4. no exceptions/SEH/etc, RTTI or other C++ frills that bloat code or stack Why do I do it? Primarily for that sweet sweet RAII, but also general source management. Classes can keep everything together. HPP based libraries are useful for simplifying distribution. public and private members replace the need for hiding in C files in many cases. and many other reasons. Should I not be doing it? Is there a reason this is bad form? Is there a reason you wouldn't?
Real programmers use butterflies
Who needs inheritance in embedded world?
Behzad
-
This is something I'm really curious about, and maybe it's just because I'm newish to coding small gadgets, though most of it is comfortable to me since I cut my teeth on 6502 CPUs back in the day. What is the purpose of writing new code in C for targeting, well ... anything? I've put away my C compiler and simply relied on limited use of C++ features to keep the footprint the same as it is in C: 1. no vtables. slightly complicates inheritance, as you can no longer do virtual ~foo() {} 2. extremely limited use of the STL, if at all. I typically use std::atomic if available, but not std::string, for example 3. judicious use of extern "C" when exporting my main, or importing "C" headers 4. no exceptions/SEH/etc, RTTI or other C++ frills that bloat code or stack Why do I do it? Primarily for that sweet sweet RAII, but also general source management. Classes can keep everything together. HPP based libraries are useful for simplifying distribution. public and private members replace the need for hiding in C files in many cases. and many other reasons. Should I not be doing it? Is there a reason this is bad form? Is there a reason you wouldn't?
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
-
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
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
-
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
-
i would use C as a personal preference. it's subjective. also i rather be in company of C programmers than C++, that is also one reason you would use a particular language. but, i assume you posted a question to get some objective info as why C is a better choice than C++ in your use case scenario. maybe it is not. C++ was designed by Bjarne with zero cost abstractions in mind - "What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better." lots of people in the game making business use C style code with the C++ compiler or as little as possible classes, shallow hierarchies and such. the C++ compiler is a powerful beast and we (the programmers) are in the business of automation. so in that sense it's a better choice. C++ does not force you to use it in any way, that's good. i think Bjarne was hot on the OOP subject, if you read early editions of the book, but not so any more. he merely says C++ gives you complete support for OOP if you want it, among other things. here is a statement from Bjarne's book that you may consider when programming embedded - "Except for the new, delete, typeid, dynamic_cast, throw operators and the try block, individual C++ expressions and statements need no run-time support." for myself, i don't dislike OOP as a technical solution and capability. i dislike object orientation in people. that philosophy, look everything is an "object" and everything is related in hierarchies, took a wrong turn. instead of a solution for a problem it became a problem of it's own and a philosophy of life. solving the problem of say input data > processing > output data with classes and objects (if you like) became looking at classes as something that has a life of it's own. carried away by work on the class rather then on the whole... you know what i mean, that thing: this is a car and a car is a vehicle. then in the boom of OOP it became, either you do it our way or the highway.
I don't look at C++ as C with objects. If anything I look at it as C with templates. Classes are just fancy structs anyway, and overuse of OO is for the birds, although admittedly I use more OOP than Generic Programming in C++ when I'm coding embedded, mostly because of code bloat issues with GP.
Martin ISDN wrote:
everything is an "object" and everything is related in hierarchies, took a wrong turn.
I have a problem with those people too - particularly if they're calling themselves C++ developers. If you want an object oriented language, learn C#. That's not what C++ is about. You *can* use it that way, but I can also use my C compiler as an assembler by wrapping everything with asm {}.. it doesn't mean it's a great idea.
Real programmers use butterflies
-
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: ```c++ template 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](https://vittorioromeo.info/index/blog/passing\_functions\_to\_functions.html) explains it more. I've seen other `std:function` alternatives as well - [this one, here on CodeProject](https://www.codeproject.com/articles/11015/the-impossibly-fast-c-delegates) was one of the first I saw, IIRC.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
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: ```c++ template 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](https://vittorioromeo.info/index/blog/passing\_functions\_to\_functions.html) explains it more. I've seen other `std:function` alternatives as well - [this one, here on CodeProject](https://www.codeproject.com/articles/11015/the-impossibly-fast-c-delegates) 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
-
I like that C/C++ is "multi-paradigm" and I wish C# were too.
C++ is anyway. I wouldn't say C is. It's got one mode - "the hard way" :laugh:
Real programmers use butterflies
-
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](https://github.com/SuperV1234/vittorioromeo.info/blob/master/extra/passing\_functions\_to\_functions/function\_view.hpp) - you could just incorporate that into your build :-)
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
All the code for it is contained in [a single C++ header file](https://github.com/SuperV1234/vittorioromeo.info/blob/master/extra/passing\_functions\_to\_functions/function\_view.hpp) - 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. :-D
Real programmers use butterflies
-
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. :-D
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. ```c++ template auto foo(T const& t) { if constexpr (std::is_same_v) { 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
-
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. ```c++ template auto foo(T const& t) { if constexpr (std::is_same_v) { 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 was being facetious, because in C I believe you are often forced to cast where you don't in C++. IE, from one of my articles...
SwcTabCtrl* tabControl = (SwcTabCtrl*) tabsC[selectedTabC];
in C, whereas C++ is:
SwcTabCtrl * tabControl = tabsC[selectedTabC];
I don't remember the reason for the forcing of the cast, but I believe it is some C-ism. Anyway, I detest the first code with great detestation. You shouldn't, though, because you are a witch!
The Science of King David's Court | Object Oriented Programming with C++
This has been more-or-less a peeve of mine between C++ and C#, but when it comes to casting, or for that matter, having to use (and know the difference between!) '->' '::' and '.', if find the effective dumbing down of C# unfortunate. So - if forced to cast, perhaps it's a way to keep all the ducks in order and also letting you know there are ducks. Behind the scenes "promotions" make life easier (and in certain SQL I depend upon them) but understanding being built into the code is (in my opinion) a plus.
"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
-
This is something I'm really curious about, and maybe it's just because I'm newish to coding small gadgets, though most of it is comfortable to me since I cut my teeth on 6502 CPUs back in the day. What is the purpose of writing new code in C for targeting, well ... anything? I've put away my C compiler and simply relied on limited use of C++ features to keep the footprint the same as it is in C: 1. no vtables. slightly complicates inheritance, as you can no longer do virtual ~foo() {} 2. extremely limited use of the STL, if at all. I typically use std::atomic if available, but not std::string, for example 3. judicious use of extern "C" when exporting my main, or importing "C" headers 4. no exceptions/SEH/etc, RTTI or other C++ frills that bloat code or stack Why do I do it? Primarily for that sweet sweet RAII, but also general source management. Classes can keep everything together. HPP based libraries are useful for simplifying distribution. public and private members replace the need for hiding in C files in many cases. and many other reasons. Should I not be doing it? Is there a reason this is bad form? Is there a reason you wouldn't?
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; -
Typical C++ baggage is a lots of behind the scenes function calls (ctor, copy ctor,dtor,=, &adressof. So if your program must execute in a certain amount of CPU clocks then C++ is a bad choice. Such as, you do not want to slow down "fly by wire" flap extender module by unnecessary function jumps for example
I agree with you, especially in the embedded and low level stuff, every clock tick counts. With C++ a person could use abstraction and polymorphism too much and seriously hobble a quick process. I would also add C is geared towards being closer to the metal and C++ more towards large applications, not that you can't do either in both. just use the right tool for the right job. personally I prefer the simplicity of the C language, there is a reason why it still is so popular on the TIOBE index
-
This is something I'm really curious about, and maybe it's just because I'm newish to coding small gadgets, though most of it is comfortable to me since I cut my teeth on 6502 CPUs back in the day. What is the purpose of writing new code in C for targeting, well ... anything? I've put away my C compiler and simply relied on limited use of C++ features to keep the footprint the same as it is in C: 1. no vtables. slightly complicates inheritance, as you can no longer do virtual ~foo() {} 2. extremely limited use of the STL, if at all. I typically use std::atomic if available, but not std::string, for example 3. judicious use of extern "C" when exporting my main, or importing "C" headers 4. no exceptions/SEH/etc, RTTI or other C++ frills that bloat code or stack Why do I do it? Primarily for that sweet sweet RAII, but also general source management. Classes can keep everything together. HPP based libraries are useful for simplifying distribution. public and private members replace the need for hiding in C files in many cases. and many other reasons. Should I not be doing it? Is there a reason this is bad form? Is there a reason you wouldn't?
Real programmers use butterflies
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 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. :thumbsup:
Real programmers use butterflies
-
honey the codewitch wrote:
So if anything it seems a matter of education? Knowing what C++ will generate and what it won't.
Perhaps this is the biggest issue. The level of knowledge one has to earn to know how to make the compiler generate what they want and even more importantly, know what the compiler will generate when reading someone else's code. This knowledge has a cost (potentially a high cost) that needs to be maintained by the organization through the expense of time and paid experience of every developer reading or maintaining the code. That expense must be offset by the reduction in cost of using C++ features that eliminate writing boilerplate code and organizing code. I suspect with the far simpler rules/capabilities of C code, you have to look at a lot less code you didn't write to understand exactly what it is doing without resorting to using a debugger or looking at assembly. My current opinion is that the decision of C versus C++ would come down to the project size and the pool and expense of developers you want maintaining the code. Imagine a "C++ developer" jumping into a project that required diagnosing a set of code that used partial and full template specialization a few levels deep and being asked to refactor it. Could they do it? The statements "I know C++" and "I know C" carry two different levels of trust. I would trust most people who claim to know C and I can easily test their knowledge. With C++, the question for me becomes, what parts of C++ do you know and how well do you know each?
Dave B
Yeah, I've seen some template stuff in C++ that seemed like voodoo to me. Just take a look at Spirit++[^] to see what I mean.
#SupportHeForShe Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun